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: Define a fixed sample stream from B210 (Marcus M?ller)
2. Re: USRP B210 queries (Marcus D. Leech)
3. Re: count number of times that a block runs in gnuradio
(Marcus M?ller)
4. Fwd: Re: 1Tx-2Rx Configuration (siva sankar)
5. Pulse width Transmission on sdr (Rana Arslan Ahmad)
6. Re: Pulse width Transmission on sdr (Neel Pandeya)
7. Re: Pulse width Transmission on sdr (Marcus M?ller)
8. Re: Change USRP sink center frequency dynamically (Martin Braun)
9. Re: Change USRP sink center frequency dynamically (Richard Bell)
10. Re: Pulse width Transmission on sdr (Neel Pandeya)
11. Re: Pulse width Transmission on sdr (Rana Arslan Ahmad)
12. PC performance optimization (Rob Kossler)
13. Re: Spikes in b210 received data (Tom Tsou)
14. Re: Pulse width Transmission on sdr (Marcus M?ller)
15. Re: PC performance optimization (Neel Pandeya)
16. X300 w/ GPSDO PPS Drift (Peter Witkowski)
17. Re: PC performance optimization (Rob Kossler)
18. Re: PC performance optimization (Michael West)
19. Re: PC performance optimization (Neel Pandeya)
20. Re: PC performance optimization (Rob Kossler)
21. Re: PC performance optimization (Rob Kossler)
22. Re: PC performance optimization (Rob Kossler)
23. Re: zpu-elf-gcc not compiling correctly (Marcus M?ller)
24. Re: Sending samples to USRP2 using "tx_samples_from_file"
(Marcus M?ller)
25. Re: PC performance optimization (Michael West)
26. Re: 4 Channel Synchronization with 2 X-300s (Michael West)
27. Re: Pulse width Transmission on sdr (Rana Arslan Ahmad)
28. Re: Pulse width Transmission on sdr (Marcus M?ller)
29. Re: Pulse width Transmission on sdr (Rana Arslan Ahmad)
30. Re: Pulse width Transmission on sdr (Marcus M?ller)
31. Errors while building fpga RFNOC X300 image (Anselm Karl)
----------------------------------------------------------------------
Message: 1
Date: Wed, 25 Mar 2015 17:07:09 +0100
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Define a fixed sample stream from B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Luis,
I think you might be referring to the number of samples that come out of
a GNU Radio UHD USRP source?
You'd normally get as many samples as the B210 gives you per USB packet
(which is a number around 250), and only get so many at once if the
blocks you've connected downstream consume samples in large chunks. That
is one of the strengths of GNU Radio: it optimizes troughput.
If you do set_max_output_items [1] on a block downstream of the USRP
source (or the source itself), you can limit that number, and hence
latency. Be a bit careful, please, since that messes with scheduling.
Best regards,
Marcus
[1]
http://gnuradio.org/doc/doxygen/classgr_1_1block.html#ae2405dc2f6c84bb8e59aab56e4ce9d84
On 03/25/2015 09:47 AM, Luis urday via USRP-users wrote:
> Hello,
>
> I would like to know if i can fix the same number of samples when i
> receive a paquet from B210 , the numbers of samples is not the same
> every time that the flowgraph runs.
> Actually the size of my paquets are around 8000 and 9000 samples, but
> sometimes i have a paquet size of 4.
>
> Regards
>
> Luis
>
>
>
> _______________________________________________
> 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/20150325/690a14e3/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 25 Mar 2015 12:09:47 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP B210 queries
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 03/25/2015 11:45 AM, Marcus D. Leech via USRP-users wrote:
> Because your computer is dividing its time between your SDR task
> (writing samples coming in at 40MB/sec), and the other things you want
> to do. Your computer has many shared resources, including CPU, memory
> space, memory bandwidth, disk bandwidth, etc, etc.
>
> Since SDR is an inherently "hard real time" task--its sampling the
> physical world, which cannot be "put on hold while I catch up", if
> there aren't
> enough system resources to support the offered load, overruns are
> inevitable.
>
Another, somewhat-related issue is that rx_samples_to_file is a
single-threaded application, intended as an example, but not necessarily
having the highest-possible sample-writes-to-file performance.
If you have Gnu Radio installed, you can try uhd_rx_cfile which
inherently takes advantage of Gnu Radio's multi-threading and
buffer-management
subsystems.
We've tried to keep the UHD examples fairly simple, but this means that
they don't always provide highest possible performance at higher
sample rates.
Your other option is to modify rx_samples_to_file so that it uses two
threads, with a ring-buffer between the threads--one thread to gather
samples
from the USRP, the other to write to the file.
>
>>
>> On Wed, Mar 25, 2015 at 7:59 PM, Marcus D. Leech <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> On 03/25/2015 02:01 AM, mvprasad k wrote:
>>
>> Hi,
>>
>> 1. I have attached system_specs.html file.
>> 2. The output of 30-second capture is as follows....The
>> overruns are varying from execution to execution slightly
>>
>> #############################OVERRUNS################18
>> Overruns########
>> ./rx_samples_to_file.exe --freq 80e6 --rate 10e6 --time 30
>> linux; GNU C++ version 4.9.1; Boost_105500;
>> UHD_003.008.002-80-ge28d7844
>>
>> 4.I have tried rx_samples_to_file with /dev/null as the
>> written-to "file". I'm not getting overruns. But it is not
>> writing to any file i think. The data is not writing to the
>> disk which serves no purpose. Even if if run
>> rx_samples_to_file without writing the data to
>> usrp_samples.dat file/writing on to the console, i won't get
>> overruns. kindly give clarity on this.
>>
>> Kindly share your ideas to overcome this problem. Specify the
>> required PC specs if my PC is not up to the standard for this
>> application.
>>
>> The purpose of my having you write to "/dev/null" is precisely to
>> isolate the cause of the overruns. If you didn't get overruns
>> when writing to /dev/null,
>> the the problem isn't in your USB stack or UHD, or even
>> rx_samples_to_file. It's that writing 40MByte/second to your
>> hard disk system
>> (10Msps X 4-bytes per complex sample) simply isn't possible on
>> your system. Your system cannot sustain disk-write rates of
>> 40Mbyte/second.
>>
>> You'll need a faster disk.
>>
>>
>>
>
>
>
> _______________________________________________
> 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/20150325/58627d41/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 25 Mar 2015 17:16:47 +0100
From: Marcus M?ller <[email protected]>
To: [email protected]
Cc: GNURadio Discussion List <[email protected]>
Subject: Re: [USRP-users] count number of times that a block runs in
gnuradio
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Luis,
that is a very GNU Radio-centric question; hence, I've taken the freedom
to include the discuss-gnuradio mailing list. I'd recommend signing up
[1] for that, and discussing further things on there.
Generally, you should easily be able to integrate that functionality
into any block, by altering its work function. I recommend getting to
know GNU Radio programming by following GNU Radio's guided tutorials
[2]. In essence, every block is a class in C++ or python, and can hold
state (such as count of times the work function was called with input)
internally.
Please be aware, though, that this is not how GNU Radio is supposed to
be used: The scheduler will offer you how many items (samples) are
ready for input, and will allow you to produce as many as there is space
to do so. If you need constant workload size, I'd recommend using
set_output_multiple [3] and a sync block[4].
Best regards,
Marcus
[1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[2] https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
[3]
http://gnuradio.org/doc/doxygen/classgr_1_1block.html#a63d67fd758b70c6f2d7b7d4edcec53b3
[4]
https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GNU_Radio_in_Python#331-Choosing-a-Block-Type
On 03/25/2015 10:00 AM, Luis urday via USRP-users wrote:
> Hello,
>
> How can i count the number of times that a block Receives a packet in
> gnuradio ?
> I tried to make a variable that increments but this variable is
> reinitialized every Time that the flowgraph restart automatically and
> a new packet is received by the block .
> I use B210 from ettus .
>
> Regards
>
> Luis
>
>
> _______________________________________________
> 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/20150325/d5aba007/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 25 Mar 2015 22:07:13 +0530
From: siva sankar <[email protected]>
To: [email protected]
Subject: [USRP-users] Fwd: Re: 1Tx-2Rx Configuration
Message-ID:
<CAAubjiXXpmCR2SkFvia=ivQ1ok=nkgcwbq+ddootj2wgtzp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
---------- Forwarded message ----------
From: "Marcus D. Leech" <[email protected]>
Date: Mar 25, 2015 9:16 PM
Subject: Re: [USRP-users] 1Tx-2Rx Configuration
To: "siva sankar" <[email protected]>
Cc:
On 03/25/2015 11:32 AM, siva sankar wrote:
Hey Marcus,
The UHD version is 3.7.2 and we didn't have any overflows. We did use a
lower clock rate (15.3Mhz) as still got the same results.
Thanks.
Siva
You really should update to the most recent UHD, which is 3.8.2
On Mar 25, 2015 8:12 PM, "Marcus D. Leech via USRP-users" <
[email protected]> wrote:
> On 03/25/2015 07:41 AM, siva sankar via USRP-users wrote:
>
> Sorry, i realised the font is too small. I am sending it again.
>
>
> Hello all,
>
> I am trying 1-Tx(channel 0) and 2-Rx configuration on the B210
> transmitting a sine wave and trying to receive at both the ends, the code
> has been compiled and on running the program 2 receiver LEDs (green) and a
> transmitter led glow simultaneously, the received stream is written into a
> .dat file.
>
> On GNU Radio Companion (GRC) the .dat file is then is extracted using a
> file source and plotted using a time sink. The output that I think I?m
> getting is noise.
>
> //create a receive streamer
> uhd::stream_args_t stream_args("fc32" , "sc16");
> std::vector<size_t> vect_channels;
> vect_channels.push_back(0);
> vect_channels.push_back(1);
> stream_args.channels = vect_channels;
> uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);
> This is how I?m creating the Receive streamer and then set all RX
> parameters like we would in a 1Tx-1Rx setup by adding an extra line and
> changing the channel index.
>
> I tried to do the same using GRC, with one USRP sink and a USRP source
> with 2 channels and then plot using time sink. The output is same as that
> of the UHD program.
>
> Also, when we try to use two USRP source blocks and with different subdev
> specs for both, only one of the two Rx LEDs come on while the time sink
> connected to said source does show a waveform.
>
> Attached are screenshots of the flow graph and the output observed.
>
> Any help is appreciated.
>
> Thanks and regards
>
> Siva.
>
> What version of UHD are you using?
>
> Do you receive any error messages?
>
> Have you tried using a lower master-clock rate? There are currently
> issues with master-clock rates at or above the 30MHz range for 2 X 2
> operation.
>
>
>
>
> _______________________________________________
> 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/20150325/47431f6f/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 25 Mar 2015 09:53:53 -0700
From: Rana Arslan Ahmad <[email protected]>
To: [email protected]
Subject: [USRP-users] Pulse width Transmission on sdr
Message-ID:
<CAAj55CYt6uJzRz61wEcfTbO9oLgzbRUPut_=ectbyipcxbq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey all,
I want to generate a pulse of 10ms and then modulate it and transmit on 1
GHz.
Is it possible with Gnuradio or any other framework of USRP??
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150325/cbfddf85/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 25 Mar 2015 10:07:55 -0700
From: Neel Pandeya <[email protected]>
To: Rana Arslan Ahmad <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Pulse width Transmission on sdr
Message-ID:
<CACaXmv8eUpuam5tspW5VSm4urs=WkFwgpA5YF=3x4gfv6pm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Yes, this should be possible using UHD directly or with GNU Radio.
Which USRP and daughterboard are you using?
Could you provide more details about what you want to do? What kind of
pulse? 10 ms, 50% duty cycle? What kind of modulation?
--Neel
On 25 March 2015 at 09:53, Rana Arslan Ahmad via USRP-users <
[email protected]> wrote:
> Hey all,
>
> I want to generate a pulse of 10ms and then modulate it and transmit on 1
> GHz.
>
> Is it possible with Gnuradio or any other framework of USRP??
>
> Thanks
>
> _______________________________________________
> 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/20150325/1d445bdd/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 25 Mar 2015 18:09:26 +0100
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Pulse width Transmission on sdr
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Rana,
yes, of course, that's what USRPs are for: taking digital I/Q samples,
converting them to an analog baseband signal, and mixing them to RF.
If you want to do this with GNU Radio, I'd recommend reading through the
Guided Tutorials [1]. You'll see that it's easy to produce arbitrary
signals, and transmit them using the USRP. There's even a dedicated
chapter on talking to hardware.
Best regards,
Marcus
[1] https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
On 03/25/2015 05:53 PM, Rana Arslan Ahmad via USRP-users wrote:
> Hey all,
>
> I want to generate a pulse of 10ms and then modulate it and transmit
> on 1 GHz.
>
> Is it possible with Gnuradio or any other framework of USRP??
>
> Thanks
>
>
> _______________________________________________
> 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/20150325/619636ce/attachment-0001.html>
------------------------------
Message: 8
Date: Wed, 25 Mar 2015 10:10:18 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Change USRP sink center frequency
dynamically
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Try the tx_freq tags. They are described on the GNU Radio manual page,
and you can find a frequency hopping example (written in Python) in the
gr-uhd/examples directory.
M
On 25.03.2015 01:52, Luis urday via USRP-users wrote:
> Hello,
>
> How can i change the USRP_sink frequency from a block in GNU radio ?
>
> I need to make a sweep to send a sinus signal from 900 Mhz to 2000 Mhz
> with a step of 20 Khz the faster possible.
>
> Regards
>
> Luis
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 9
Date: Wed, 25 Mar 2015 10:12:29 -0700
From: Richard Bell <[email protected]>
To: Luis urday <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Change USRP sink center frequency
dynamically
Message-ID:
<CAMMoi3v8y6Em4Q+B=zshsht_jzw7zvfnbsmy9rh9hbg220y...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Luis,
You can use a QT GUI Range block that creates a slider which dynamically
changes the variable during runtime. Use this variable in the field for the
USRP Sink and you have a runtime configurable setup.
If you want programatic control, then you should look at the singing sine
wave in the guided tutorials. Section 2.4.5. You should go through all the
tutorials if you're new to this.
https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GRC
v/r,
Rich
On Wed, Mar 25, 2015 at 1:52 AM, Luis urday via USRP-users <
[email protected]> wrote:
> Hello,
>
> How can i change the USRP_sink frequency from a block in GNU radio ?
>
> I need to make a sweep to send a sinus signal from 900 Mhz to 2000 Mhz
> with a step of 20 Khz the faster possible.
>
> Regards
>
> Luis
>
> _______________________________________________
> 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/20150325/c98fec63/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 25 Mar 2015 10:29:46 -0700
From: Neel Pandeya <[email protected]>
To: Rana Arslan Ahmad <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Pulse width Transmission on sdr
Message-ID:
<CACaXmv-c0jyE=RrQLevBpdmiir1PcHL6p1bKyiGfdxSU=bu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Please keep this conversation on the mailing list.
If I recall, you're using E110, right?
Which daughterboard?
What kind of modulation?
--Neel
On 25 March 2015 at 10:19, Rana Arslan Ahmad <[email protected]> wrote:
> I am using USRP embedded series. Actually I want to transmit a pulse
> train. Probably 60% duty cycle with respective modulation.
> Yes, this should be possible using UHD directly or with GNU Radio.
>
> Which USRP and daughterboard are you using?
>
> Could you provide more details about what you want to do? What kind of
> pulse? 10 ms, 50% duty cycle? What kind of modulation?
>
> --Neel
>
>
>
> On 25 March 2015 at 09:53, Rana Arslan Ahmad via USRP-users <
> [email protected]> wrote:
>
>> Hey all,
>>
>> I want to generate a pulse of 10ms and then modulate it and transmit on 1
>> GHz.
>>
>> Is it possible with Gnuradio or any other framework of USRP??
>>
>> Thanks
>>
>> _______________________________________________
>> 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/20150325/9345743b/attachment-0001.html>
------------------------------
Message: 11
Date: Wed, 25 Mar 2015 10:36:58 -0700
From: Rana Arslan Ahmad <[email protected]>
To: Neel Pandeya <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Pulse width Transmission on sdr
Message-ID:
<CAAj55CZ1zvUr-=f6h0d1sou+-wo-gqrb9mtdx6snafxtaz2...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
ok and you're right, at the moment looking forward to work on E110 for time
being or maybe order E310 soon.
I don't have much experience of Gnuradio programming but I've done a lot of
digital communications labs via MATLAB.
WBX daughterboard.
On Wed, Mar 25, 2015 at 10:29 AM, Neel Pandeya <[email protected]>
wrote:
> Please keep this conversation on the mailing list.
>
> If I recall, you're using E110, right?
> Which daughterboard?
>
> What kind of modulation?
>
> --Neel
>
>
>
> On 25 March 2015 at 10:19, Rana Arslan Ahmad <[email protected]> wrote:
>
>> I am using USRP embedded series. Actually I want to transmit a pulse
>> train. Probably 60% duty cycle with respective modulation.
>> Yes, this should be possible using UHD directly or with GNU Radio.
>>
>> Which USRP and daughterboard are you using?
>>
>> Could you provide more details about what you want to do? What kind of
>> pulse? 10 ms, 50% duty cycle? What kind of modulation?
>>
>> --Neel
>>
>>
>>
>> On 25 March 2015 at 09:53, Rana Arslan Ahmad via USRP-users <
>> [email protected]> wrote:
>>
>>> Hey all,
>>>
>>> I want to generate a pulse of 10ms and then modulate it and transmit on
>>> 1 GHz.
>>>
>>> Is it possible with Gnuradio or any other framework of USRP??
>>>
>>> Thanks
>>>
>>> _______________________________________________
>>> 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/20150325/9391b46c/attachment-0001.html>
------------------------------
Message: 12
Date: Wed, 25 Mar 2015 13:48:45 -0400
From: Rob Kossler <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] PC performance optimization
Message-ID:
<CAB__hTRmsSU1xAtApW_YD-sQimXDN5q9O+7Ac_wYO=ye8ps...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I just bought a new PC for use with an X310 and attempted to configure it
according to the instructions here (
http://files.ettus.com/manual/page_usrp_x3x0_config.html). Subsequently,
I tested the configured PC using "benchmark_rate" (2 chan, full duplex, 100
MS/s). After getting lots of underruns and after doing some investigation,
I noticed something strange. My CPU speed as reported by "cpufreq-info"
was at 1.2 GHz rather than 3.5 GHz.
I double-checked that the file "/etc/init.d/cpufrequtils" was configured
for the "performance" governor setting. Then, I noticed that immediately
after bootup, the freq was set to 3.5GHz and the governor was set to
"performance" as expected. However, without running anything besides
"cpufreq-info", I noticed that after about 30 secs or so, the governor
setting unexpectedly changed to "ondemand" and the freq setting dropped to
1.2 GHz. If I subsequently restart cpufrequtils using "sudo
/etc/init.d/cpufrequtils restart", it then seems to stay in the
"performance" setting forever.
Does anyone know why this setting would change (and/or how I can stop it
from doing so)? Looking online, I noticed that there can sometimes be a
conflict with "laptop-mode-tools", but this PC is not a laptop and I don't
have this package installed.
Rob Kossler
PC Info
Model: HP Z440 Workstation
CPU: Xeon E5-1620 v3
RAM: 32GB DDR4
10Gb: Intel X520-DA2 (previously used successfully in another PC)
UHD Info
- 3.8.2 compiled from source, installed via PyBOMBS
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150325/73110571/attachment-0001.html>
------------------------------
Message: 13
Date: Wed, 25 Mar 2015 10:50:49 -0700
From: Tom Tsou <[email protected]>
To: Arjun Nadh <[email protected]>
Cc: Usrp-users <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Spikes in b210 received data
Message-ID:
<caatym+zal9z+jxzuoelow_b8ofq772hy5nhkfmo9kjv_yf4...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Tue, Mar 24, 2015 at 11:07 PM, Arjun Nadh <[email protected]> wrote:
> Thank you, Tom
> That fixes the problem.
Great. Thanks for testing.
Upcoming UHD and gr-uhd changes will expose more of the AD9361
functionality, which will allow user control of calibration and
filters without having to patch UHD. We're also looking into better
tuning of the calibration tracking to avoid such signal oddities.
-TT
> On Wed, Mar 25, 2015 at 1:47 AM, Tom Tsou <[email protected]> wrote:
>>
>> Hi Arjun,
>>
>> Can you try the attached patch against UHD master and see if you see
>> the same effects?
>>
>> We've seen various cases of similar, though not exact, behavior on
>> B200. Rx quadrature tracking is the usual cause, which this patch
>> disables.
>>
>> -TT
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ad9361-Disable-IQ-tracking.patch
Type: text/x-patch
Size: 1024 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150325/f9d2f42b/attachment-0001.patch>
------------------------------
Message: 14
Date: Wed, 25 Mar 2015 18:51:04 +0100
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Pulse width Transmission on sdr
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
One thing you should note is that I personally don't recommend using the
Embedded E-series devices for prototyping of signal waveforms. These
devices integrate an embedded linux machine with USRP hardware, which
makes it very easy to develop applications that require standalone
operation, for example remote sensors, base stations, beacons, etc.
However, if you want to prototype your RF application, it's general
advisable to not start with the embedded device, but with one of the
peripheral USRPs (B2x0, N2x0, X3x0), since these allow execution of your
SDR software on a real PC, and take the burden of developing and
debugging for/on an embedded platform of your shoulders. The E310 and
E110 are specialized pieces of embedded hardware, which, for example,
means that you can't run matlab on it. Depending on your toolboxes, you
might be able to export code that you can compile for these platforms,
but that requires that you have the time to get to know a bit about
software development.
If you use a peripheral USRP and develop your software on a linux PC,
once you have a proof of concept, transferring the software to the
embedded device will usually be relatively easy -- the UHD driver
running on the embedded devices has exactly the same interface as UHD
running on a full PC, talking to a peripheral USRP, over network, PCIe
or USB, and after all, it's running a normal linux kernel.
A typical GNU Radio based workflow would be to design one's flow graph
in the GNU Radio companion interface graphically, if necessary writing
one's own signal processing blocks in Python or C++, and verifying
operation on the PC with a peripheral USRP. When everything works, one
would simply take the resulting code, and compile (only necessary if C++
was used) it for the E310/E110, and copy it to the embedded device.
Greetings,
Marcus
On 03/25/2015 06:36 PM, Rana Arslan Ahmad via USRP-users wrote:
> ok and you're right, at the moment looking forward to work on E110 for
> time being or maybe order E310 soon.
> I don't have much experience of Gnuradio programming but I've done a
> lot of digital communications labs via MATLAB.
>
> WBX daughterboard.
>
> On Wed, Mar 25, 2015 at 10:29 AM, Neel Pandeya <[email protected]
> <mailto:[email protected]>> wrote:
>
> Please keep this conversation on the mailing list.
>
> If I recall, you're using E110, right?
> Which daughterboard?
>
> What kind of modulation?
>
> --Neel
>
>
>
> On 25 March 2015 at 10:19, Rana Arslan Ahmad <[email protected]
> <mailto:[email protected]>> wrote:
>
> I am using USRP embedded series. Actually I want to transmit a
> pulse train. Probably 60% duty cycle with respective modulation.
>
> Yes, this should be possible using UHD directly or with GNU Radio.
>
> Which USRP and daughterboard are you using?
>
> Could you provide more details about what you want to do? What
> kind of pulse? 10 ms, 50% duty cycle? What kind of modulation?
>
> --Neel
>
>
>
> On 25 March 2015 at 09:53, Rana Arslan Ahmad via USRP-users
> <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hey all,
>
> I want to generate a pulse of 10ms and then modulate it
> and transmit on 1 GHz.
>
> Is it possible with Gnuradio or any other framework of USRP??
>
> Thanks
>
> _______________________________________________
> 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]
> 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/20150325/fdb0e5e0/attachment-0001.html>
------------------------------
Message: 15
Date: Wed, 25 Mar 2015 11:22:55 -0700
From: Neel Pandeya <[email protected]>
To: Rob Kossler <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] PC performance optimization
Message-ID:
<cacaxmv-tkt0eva2jyjvqo_0dq_wr2q2hzhf0cw7mxbafsie...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Rob:
Perhaps your CPU has Intel SpeedStep (aka EIST) enabled, and you may need
to disable it in the BIOS?? This is the only reason that I can think of at
the moment as to why you'd see the behavior that you're seeing. Indeed, the
"performance" governor is the governor setting that you want, but I don't
understand why it's dynamically changing. I think it's due to Intel
SpeedStep.
Also, you may need to specify the CPU frequency separately from the
governor setting. Set the governor, and then set the CPU frequency to the
maximum possible.
Please let us know if any of this works/helps.
--Neel
On 25 March 2015 at 10:48, Rob Kossler via USRP-users <
[email protected]> wrote:
> I just bought a new PC for use with an X310 and attempted to configure it
> according to the instructions here (
> http://files.ettus.com/manual/page_usrp_x3x0_config.html).
> Subsequently, I tested the configured PC using "benchmark_rate" (2 chan,
> full duplex, 100 MS/s). After getting lots of underruns and after doing
> some investigation, I noticed something strange. My CPU speed as reported
> by "cpufreq-info" was at 1.2 GHz rather than 3.5 GHz.
>
> I double-checked that the file "/etc/init.d/cpufrequtils" was configured
> for the "performance" governor setting. Then, I noticed that immediately
> after bootup, the freq was set to 3.5GHz and the governor was set to
> "performance" as expected. However, without running anything besides
> "cpufreq-info", I noticed that after about 30 secs or so, the governor
> setting unexpectedly changed to "ondemand" and the freq setting dropped to
> 1.2 GHz. If I subsequently restart cpufrequtils using "sudo
> /etc/init.d/cpufrequtils restart", it then seems to stay in the
> "performance" setting forever.
>
> Does anyone know why this setting would change (and/or how I can stop it
> from doing so)? Looking online, I noticed that there can sometimes be a
> conflict with "laptop-mode-tools", but this PC is not a laptop and I don't
> have this package installed.
>
> Rob Kossler
>
> PC Info
> Model: HP Z440 Workstation
> CPU: Xeon E5-1620 v3
> RAM: 32GB DDR4
> 10Gb: Intel X520-DA2 (previously used successfully in another PC)
>
> UHD Info
> - 3.8.2 compiled from source, installed via PyBOMBS
>
> _______________________________________________
> 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/20150325/4382d378/attachment-0001.html>
------------------------------
Message: 16
Date: Wed, 25 Mar 2015 14:49:16 -0400
From: Peter Witkowski <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] X300 w/ GPSDO PPS Drift
Message-ID:
<CAN1Qg3N0OzHgtK_m3pjN=vvpo3v8_nzg-9vt_kxsoivxagy...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
I am currently experiencing a rather puzzling issue trying to get a few
X300s to synchronize together. Each X300 has a GPSDO installed (the OCXO
model).
When I first boot up each X300, I see no reference, PPS, or GPS lights on
(I'm assuming this is normal). I then run uhd_usrp_probe and the reference
and PPS lights start working. After some time (about ten to twenty minutes
or so) the GPS light comes on. Note that even before the GPS light comes
on, I can query the GPS and it shows 12 satellites and a good GPS position
and lock.
During this time, I am monitoring the PPS Out (via an oscilloscope) of each
USRP to note whether or not the PPS signals are within spec. After about
an hour or so, all the PPS signals are very tightly coupled (well within
the spec of +/- 50ns. In fact, many of the signals are within +/-10 ns or
even better.
However, when I go to start a program that receives signal data (either my
own custom UHD application or uhd_fft), bad things happen. Here's what I'm
seeing (note that I did a bit of debugging to note exactly where this is
all happening).
1. When the UHD driver prints "Detecting Internal GPSDO" the PPS totally
drops off of my scope. Hitting Ctrl+C during this time puts the X300 in a
weird state where I can't see the PPS Out signal at all and the PPS light
is noticeably different than the lights on the other units.
2. When the UHD driver prints "Initializing clock and time using GPSDO"
the PPS comes back in the same spot that it was prior to starting the
program.
3. The PPS will now drift wildly over time (+/- 200ns) leading me to
believe it is no longer properly locked. It takes anywhere from one hour
to several hours for the PPS to now steady itself.
As a result, it would appear that when running any UHD program, the GPSDO
is re-initialized, and drops its previously well established
synchronization and lock. The UHD driver appears to be agnostic of whether
or not the GPS is well synchronized or if it has just been powered on for
the first time.
I've also noted that this problem seems to occur regardless of daughtercard
selection (tried both a WBX-120 and a CBX-120). Also, the problem is
independent of which channel the daughtercard is plugged into as well.
A final note is that this problem doesn't seem to occur when doing a
uhd_usrp_probe, which uses the "device" interface (instead of multi_usrp)
in terms of the UHD API. The PPS still drops out, but when it comes back,
there is no drift.
As a result, I'm wondering if there's a way to tell UHD to skip any GPSDO
re-initialization when running a program. Also, is there a way to
automatically get the GPSDO to come up and lock after power up (i.e., so I
don't have to run a uhd_usrp_probe)? My ideal use case would be to power
up my USRPs, allow them to get a good GPS synch, and then start my data
collection without disturbing the previously established synch.
Thanks for the assistance.
--
Peter Witkowski
[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150325/0554213e/attachment-0001.html>
------------------------------
Message: 17
Date: Wed, 25 Mar 2015 15:32:54 -0400
From: Rob Kossler <[email protected]>
To: Neel Pandeya <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] PC performance optimization
Message-ID:
<cab__httmot3l4kb0h-fbmajkc8ycvdwq9nj3ey1yqy4x62b...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Looking at the CPU specs (Xeon E5-1620 v3), it does appear to support
EIST. But, I can't find anything in the HP M60 BIOS (v 1.21) related to
such a setting. BTW, there is a newer bios (1.25A) that I plan to install
later today....
Regarding the speed settings, I am indeed able to change the MIN speed to
3.5GHz. When I reboot now, the CPU setting always reports as 3.5GHz, but
the governor changes as before. That is, it starts out as "performance"
and then unexpectedly changes to "ondemand" after 30 secs or so. I'm
wondering if this is worth worrying about or not. Perhaps as long as the
CPU stays at 3.5GHz, that is all that matters. Or, perhaps some other
settings are affected by the "ondemand" governor or whatever is triggering
the governor setting to change. Not really sure on this???
Rob
On Wed, Mar 25, 2015 at 2:22 PM, Neel Pandeya <[email protected]>
wrote:
> Hello Rob:
>
> Perhaps your CPU has Intel SpeedStep (aka EIST) enabled, and you may need
> to disable it in the BIOS?? This is the only reason that I can think of at
> the moment as to why you'd see the behavior that you're seeing. Indeed, the
> "performance" governor is the governor setting that you want, but I don't
> understand why it's dynamically changing. I think it's due to Intel
> SpeedStep.
>
> Also, you may need to specify the CPU frequency separately from the
> governor setting. Set the governor, and then set the CPU frequency to the
> maximum possible.
>
> Please let us know if any of this works/helps.
>
> --Neel
>
>
>
> On 25 March 2015 at 10:48, Rob Kossler via USRP-users <
> [email protected]> wrote:
>
>> I just bought a new PC for use with an X310 and attempted to configure it
>> according to the instructions here (
>> http://files.ettus.com/manual/page_usrp_x3x0_config.html).
>> Subsequently, I tested the configured PC using "benchmark_rate" (2 chan,
>> full duplex, 100 MS/s). After getting lots of underruns and after doing
>> some investigation, I noticed something strange. My CPU speed as reported
>> by "cpufreq-info" was at 1.2 GHz rather than 3.5 GHz.
>>
>> I double-checked that the file "/etc/init.d/cpufrequtils" was configured
>> for the "performance" governor setting. Then, I noticed that immediately
>> after bootup, the freq was set to 3.5GHz and the governor was set to
>> "performance" as expected. However, without running anything besides
>> "cpufreq-info", I noticed that after about 30 secs or so, the governor
>> setting unexpectedly changed to "ondemand" and the freq setting dropped to
>> 1.2 GHz. If I subsequently restart cpufrequtils using "sudo
>> /etc/init.d/cpufrequtils restart", it then seems to stay in the
>> "performance" setting forever.
>>
>> Does anyone know why this setting would change (and/or how I can stop it
>> from doing so)? Looking online, I noticed that there can sometimes be a
>> conflict with "laptop-mode-tools", but this PC is not a laptop and I don't
>> have this package installed.
>>
>> Rob Kossler
>>
>> PC Info
>> Model: HP Z440 Workstation
>> CPU: Xeon E5-1620 v3
>> RAM: 32GB DDR4
>> 10Gb: Intel X520-DA2 (previously used successfully in another PC)
>>
>> UHD Info
>> - 3.8.2 compiled from source, installed via PyBOMBS
>>
>> _______________________________________________
>> 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/20150325/c44f0682/attachment-0001.html>
------------------------------
Message: 18
Date: Wed, 25 Mar 2015 13:03:21 -0700
From: Michael West <[email protected]>
To: Rob Kossler <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] PC performance optimization
Message-ID:
<cam4xkrprqaipbm1_wb5hnhfxvdtvaugcj-nndupwp7ccs_m...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Rob,
Check for power management utilities and either disable them or make sure
their settings match what you want. What OS are you using?
Regards,
Michael
On Wed, Mar 25, 2015 at 12:32 PM, Rob Kossler via USRP-users <
[email protected]> wrote:
> Looking at the CPU specs (Xeon E5-1620 v3), it does appear to support
> EIST. But, I can't find anything in the HP M60 BIOS (v 1.21) related to
> such a setting. BTW, there is a newer bios (1.25A) that I plan to install
> later today....
>
> Regarding the speed settings, I am indeed able to change the MIN speed to
> 3.5GHz. When I reboot now, the CPU setting always reports as 3.5GHz, but
> the governor changes as before. That is, it starts out as "performance"
> and then unexpectedly changes to "ondemand" after 30 secs or so. I'm
> wondering if this is worth worrying about or not. Perhaps as long as the
> CPU stays at 3.5GHz, that is all that matters. Or, perhaps some other
> settings are affected by the "ondemand" governor or whatever is triggering
> the governor setting to change. Not really sure on this???
>
> Rob
>
> On Wed, Mar 25, 2015 at 2:22 PM, Neel Pandeya <[email protected]>
> wrote:
>
>> Hello Rob:
>>
>> Perhaps your CPU has Intel SpeedStep (aka EIST) enabled, and you may need
>> to disable it in the BIOS?? This is the only reason that I can think of at
>> the moment as to why you'd see the behavior that you're seeing. Indeed, the
>> "performance" governor is the governor setting that you want, but I don't
>> understand why it's dynamically changing. I think it's due to Intel
>> SpeedStep.
>>
>> Also, you may need to specify the CPU frequency separately from the
>> governor setting. Set the governor, and then set the CPU frequency to the
>> maximum possible.
>>
>> Please let us know if any of this works/helps.
>>
>> --Neel
>>
>>
>>
>> On 25 March 2015 at 10:48, Rob Kossler via USRP-users <
>> [email protected]> wrote:
>>
>>> I just bought a new PC for use with an X310 and attempted to configure
>>> it according to the instructions here (
>>> http://files.ettus.com/manual/page_usrp_x3x0_config.html).
>>> Subsequently, I tested the configured PC using "benchmark_rate" (2 chan,
>>> full duplex, 100 MS/s). After getting lots of underruns and after doing
>>> some investigation, I noticed something strange. My CPU speed as reported
>>> by "cpufreq-info" was at 1.2 GHz rather than 3.5 GHz.
>>>
>>> I double-checked that the file "/etc/init.d/cpufrequtils" was configured
>>> for the "performance" governor setting. Then, I noticed that immediately
>>> after bootup, the freq was set to 3.5GHz and the governor was set to
>>> "performance" as expected. However, without running anything besides
>>> "cpufreq-info", I noticed that after about 30 secs or so, the governor
>>> setting unexpectedly changed to "ondemand" and the freq setting dropped to
>>> 1.2 GHz. If I subsequently restart cpufrequtils using "sudo
>>> /etc/init.d/cpufrequtils restart", it then seems to stay in the
>>> "performance" setting forever.
>>>
>>> Does anyone know why this setting would change (and/or how I can stop it
>>> from doing so)? Looking online, I noticed that there can sometimes be a
>>> conflict with "laptop-mode-tools", but this PC is not a laptop and I don't
>>> have this package installed.
>>>
>>> Rob Kossler
>>>
>>> PC Info
>>> Model: HP Z440 Workstation
>>> CPU: Xeon E5-1620 v3
>>> RAM: 32GB DDR4
>>> 10Gb: Intel X520-DA2 (previously used successfully in another PC)
>>>
>>> UHD Info
>>> - 3.8.2 compiled from source, installed via PyBOMBS
>>>
>>> _______________________________________________
>>> 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/20150325/829239a9/attachment-0001.html>
------------------------------
Message: 19
Date: Wed, 25 Mar 2015 13:26:06 -0700
From: Neel Pandeya <[email protected]>
To: Rob Kossler <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] PC performance optimization
Message-ID:
<cacaxmv_elm-rbvm3ghtme_wbzc+b7dye1oo21bdj5uv6hk9...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Michael's post reminded me, you may also want/need to disable ACPI power
control/power management in your BIOS.
--Neel
On 25 March 2015 at 13:03, Michael West <[email protected]> wrote:
> Hi Rob,
>
> Check for power management utilities and either disable them or make sure
> their settings match what you want. What OS are you using?
>
> Regards,
> Michael
>
> On Wed, Mar 25, 2015 at 12:32 PM, Rob Kossler via USRP-users <
> [email protected]> wrote:
>
>> Looking at the CPU specs (Xeon E5-1620 v3), it does appear to support
>> EIST. But, I can't find anything in the HP M60 BIOS (v 1.21) related to
>> such a setting. BTW, there is a newer bios (1.25A) that I plan to install
>> later today....
>>
>> Regarding the speed settings, I am indeed able to change the MIN speed to
>> 3.5GHz. When I reboot now, the CPU setting always reports as 3.5GHz, but
>> the governor changes as before. That is, it starts out as "performance"
>> and then unexpectedly changes to "ondemand" after 30 secs or so. I'm
>> wondering if this is worth worrying about or not. Perhaps as long as the
>> CPU stays at 3.5GHz, that is all that matters. Or, perhaps some other
>> settings are affected by the "ondemand" governor or whatever is triggering
>> the governor setting to change. Not really sure on this???
>>
>> Rob
>>
>> On Wed, Mar 25, 2015 at 2:22 PM, Neel Pandeya <[email protected]>
>> wrote:
>>
>>> Hello Rob:
>>>
>>> Perhaps your CPU has Intel SpeedStep (aka EIST) enabled, and you may
>>> need to disable it in the BIOS?? This is the only reason that I can think
>>> of at the moment as to why you'd see the behavior that you're seeing.
>>> Indeed, the "performance" governor is the governor setting that you want,
>>> but I don't understand why it's dynamically changing. I think it's due to
>>> Intel SpeedStep.
>>>
>>> Also, you may need to specify the CPU frequency separately from the
>>> governor setting. Set the governor, and then set the CPU frequency to the
>>> maximum possible.
>>>
>>> Please let us know if any of this works/helps.
>>>
>>> --Neel
>>>
>>>
>>>
>>> On 25 March 2015 at 10:48, Rob Kossler via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> I just bought a new PC for use with an X310 and attempted to configure
>>>> it according to the instructions here (
>>>> http://files.ettus.com/manual/page_usrp_x3x0_config.html).
>>>> Subsequently, I tested the configured PC using "benchmark_rate" (2 chan,
>>>> full duplex, 100 MS/s). After getting lots of underruns and after doing
>>>> some investigation, I noticed something strange. My CPU speed as reported
>>>> by "cpufreq-info" was at 1.2 GHz rather than 3.5 GHz.
>>>>
>>>> I double-checked that the file "/etc/init.d/cpufrequtils" was
>>>> configured for the "performance" governor setting. Then, I noticed that
>>>> immediately after bootup, the freq was set to 3.5GHz and the governor was
>>>> set to "performance" as expected. However, without running anything
>>>> besides "cpufreq-info", I noticed that after about 30 secs or so, the
>>>> governor setting unexpectedly changed to "ondemand" and the freq setting
>>>> dropped to 1.2 GHz. If I subsequently restart cpufrequtils using "sudo
>>>> /etc/init.d/cpufrequtils restart", it then seems to stay in the
>>>> "performance" setting forever.
>>>>
>>>> Does anyone know why this setting would change (and/or how I can stop
>>>> it from doing so)? Looking online, I noticed that there can sometimes be a
>>>> conflict with "laptop-mode-tools", but this PC is not a laptop and I don't
>>>> have this package installed.
>>>>
>>>> Rob Kossler
>>>>
>>>> PC Info
>>>> Model: HP Z440 Workstation
>>>> CPU: Xeon E5-1620 v3
>>>> RAM: 32GB DDR4
>>>> 10Gb: Intel X520-DA2 (previously used successfully in another PC)
>>>>
>>>> UHD Info
>>>> - 3.8.2 compiled from source, installed via PyBOMBS
>>>>
>>>> _______________________________________________
>>>> 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/20150325/33a9e1ef/attachment-0001.html>
------------------------------
Message: 20
Date: Wed, 25 Mar 2015 16:28:08 -0400
From: Rob Kossler <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] PC performance optimization
Message-ID:
<cab__htqsbq+3dsamguxssrg+urbpcrn3c7l7lnqwueedzk2...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Ubuntu 14.04 LTS
I just installed it (dual boot on same hard drive as Windows) in the last
couple of days so it should be relatively "clean". It doesn't have much of
anything non-standard, non-default. Just added the stuff to make UHD /
gnuradio work.
Rob
On Wed, Mar 25, 2015 at 4:03 PM, Michael West <[email protected]>
wrote:
> Hi Rob,
>
> Check for power management utilities and either disable them or make sure
> their settings match what you want. What OS are you using?
>
> Regards,
> Michael
>
> On Wed, Mar 25, 2015 at 12:32 PM, Rob Kossler via USRP-users <
> [email protected]> wrote:
>
>> Looking at the CPU specs (Xeon E5-1620 v3), it does appear to support
>> EIST. But, I can't find anything in the HP M60 BIOS (v 1.21) related to
>> such a setting. BTW, there is a newer bios (1.25A) that I plan to install
>> later today....
>>
>> Regarding the speed settings, I am indeed able to change the MIN speed to
>> 3.5GHz. When I reboot now, the CPU setting always reports as 3.5GHz, but
>> the governor changes as before. That is, it starts out as "performance"
>> and then unexpectedly changes to "ondemand" after 30 secs or so. I'm
>> wondering if this is worth worrying about or not. Perhaps as long as the
>> CPU stays at 3.5GHz, that is all that matters. Or, perhaps some other
>> settings are affected by the "ondemand" governor or whatever is triggering
>> the governor setting to change. Not really sure on this???
>>
>> Rob
>>
>> On Wed, Mar 25, 2015 at 2:22 PM, Neel Pandeya <[email protected]>
>> wrote:
>>
>>> Hello Rob:
>>>
>>> Perhaps your CPU has Intel SpeedStep (aka EIST) enabled, and you may
>>> need to disable it in the BIOS?? This is the only reason that I can think
>>> of at the moment as to why you'd see the behavior that you're seeing.
>>> Indeed, the "performance" governor is the governor setting that you want,
>>> but I don't understand why it's dynamically changing. I think it's due to
>>> Intel SpeedStep.
>>>
>>> Also, you may need to specify the CPU frequency separately from the
>>> governor setting. Set the governor, and then set the CPU frequency to the
>>> maximum possible.
>>>
>>> Please let us know if any of this works/helps.
>>>
>>> --Neel
>>>
>>>
>>>
>>> On 25 March 2015 at 10:48, Rob Kossler via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> I just bought a new PC for use with an X310 and attempted to configure
>>>> it according to the instructions here (
>>>> http://files.ettus.com/manual/page_usrp_x3x0_config.html).
>>>> Subsequently, I tested the configured PC using "benchmark_rate" (2 chan,
>>>> full duplex, 100 MS/s). After getting lots of underruns and after doing
>>>> some investigation, I noticed something strange. My CPU speed as reported
>>>> by "cpufreq-info" was at 1.2 GHz rather than 3.5 GHz.
>>>>
>>>> I double-checked that the file "/etc/init.d/cpufrequtils" was
>>>> configured for the "performance" governor setting. Then, I noticed that
>>>> immediately after bootup, the freq was set to 3.5GHz and the governor was
>>>> set to "performance" as expected. However, without running anything
>>>> besides "cpufreq-info", I noticed that after about 30 secs or so, the
>>>> governor setting unexpectedly changed to "ondemand" and the freq setting
>>>> dropped to 1.2 GHz. If I subsequently restart cpufrequtils using "sudo
>>>> /etc/init.d/cpufrequtils restart", it then seems to stay in the
>>>> "performance" setting forever.
>>>>
>>>> Does anyone know why this setting would change (and/or how I can stop
>>>> it from doing so)? Looking online, I noticed that there can sometimes be a
>>>> conflict with "laptop-mode-tools", but this PC is not a laptop and I don't
>>>> have this package installed.
>>>>
>>>> Rob Kossler
>>>>
>>>> PC Info
>>>> Model: HP Z440 Workstation
>>>> CPU: Xeon E5-1620 v3
>>>> RAM: 32GB DDR4
>>>> 10Gb: Intel X520-DA2 (previously used successfully in another PC)
>>>>
>>>> UHD Info
>>>> - 3.8.2 compiled from source, installed via PyBOMBS
>>>>
>>>> _______________________________________________
>>>> 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/20150325/a15f5434/attachment-0001.html>
------------------------------
Message: 21
Date: Wed, 25 Mar 2015 16:45:00 -0400
From: Rob Kossler <[email protected]>
To: Neel Pandeya <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] PC performance optimization
Message-ID:
<CAB__hTS8J3xcQ8Hf87Awn=25khsm33hakzjwh3ocnu5yb2b...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I don't know specifically about "ACPI power control/power management". My
BIOS has the following:
OS Power Options (items with ** described below. First option is the
current setting)
- ** Runtime Power Management: Enable/Disable
- ** Idle Power Savings: Extended/Normal
- Unique Blink States: Disable/Enable
Additionally, the BIOS contains Performance settings.
Performance Options
- Intel HyperThreading Technology: Enable/Disable
- Active CPU Cores For Processor: All cores per processor
- PCIe Performance Mode: Enable/Disable
- ** Turbo Mode: Enable/Disable
Note: All items noted with ** indicate items that are unavailable for
setting or even viewing if the option "PCIe Performance Mode" is Enabled.
If it is Disabled (which is the default), then I can set all of the **
items. However, I presently have PCIe Performance Mode Enabled because
that "seems" to work better.
So,
1) Let me know if you have any thoughts on the Power settings. I'm not
sure if these map to "ACPI power control" or not.
2) Let me know if you have any thoughts on the PCIe Performance Mode
Enable/Disable setting. I would think that we would want this enabled even
though it is by default disabled. And the fact that the Power options are
unavailable when this is Enabled makes me think that it effectively
disables power control / management. But, I don't know that for certain.
Rob
On Wed, Mar 25, 2015 at 4:26 PM, Neel Pandeya <[email protected]>
wrote:
> Michael's post reminded me, you may also want/need to disable ACPI power
> control/power management in your BIOS.
>
> --Neel
>
>
> On 25 March 2015 at 13:03, Michael West <[email protected]> wrote:
>
>> Hi Rob,
>>
>> Check for power management utilities and either disable them or make sure
>> their settings match what you want. What OS are you using?
>>
>> Regards,
>> Michael
>>
>> On Wed, Mar 25, 2015 at 12:32 PM, Rob Kossler via USRP-users <
>> [email protected]> wrote:
>>
>>> Looking at the CPU specs (Xeon E5-1620 v3), it does appear to support
>>> EIST. But, I can't find anything in the HP M60 BIOS (v 1.21) related to
>>> such a setting. BTW, there is a newer bios (1.25A) that I plan to install
>>> later today....
>>>
>>> Regarding the speed settings, I am indeed able to change the MIN speed
>>> to 3.5GHz. When I reboot now, the CPU setting always reports as 3.5GHz,
>>> but the governor changes as before. That is, it starts out as
>>> "performance" and then unexpectedly changes to "ondemand" after 30 secs or
>>> so. I'm wondering if this is worth worrying about or not. Perhaps as long
>>> as the CPU stays at 3.5GHz, that is all that matters. Or, perhaps some
>>> other settings are affected by the "ondemand" governor or whatever is
>>> triggering the governor setting to change. Not really sure on this???
>>>
>>> Rob
>>>
>>> On Wed, Mar 25, 2015 at 2:22 PM, Neel Pandeya <[email protected]>
>>> wrote:
>>>
>>>> Hello Rob:
>>>>
>>>> Perhaps your CPU has Intel SpeedStep (aka EIST) enabled, and you may
>>>> need to disable it in the BIOS?? This is the only reason that I can think
>>>> of at the moment as to why you'd see the behavior that you're seeing.
>>>> Indeed, the "performance" governor is the governor setting that you want,
>>>> but I don't understand why it's dynamically changing. I think it's due to
>>>> Intel SpeedStep.
>>>>
>>>> Also, you may need to specify the CPU frequency separately from the
>>>> governor setting. Set the governor, and then set the CPU frequency to the
>>>> maximum possible.
>>>>
>>>> Please let us know if any of this works/helps.
>>>>
>>>> --Neel
>>>>
>>>>
>>>>
>>>> On 25 March 2015 at 10:48, Rob Kossler via USRP-users <
>>>> [email protected]> wrote:
>>>>
>>>>> I just bought a new PC for use with an X310 and attempted to configure
>>>>> it according to the instructions here (
>>>>> http://files.ettus.com/manual/page_usrp_x3x0_config.html).
>>>>> Subsequently, I tested the configured PC using "benchmark_rate" (2 chan,
>>>>> full duplex, 100 MS/s). After getting lots of underruns and after doing
>>>>> some investigation, I noticed something strange. My CPU speed as reported
>>>>> by "cpufreq-info" was at 1.2 GHz rather than 3.5 GHz.
>>>>>
>>>>> I double-checked that the file "/etc/init.d/cpufrequtils" was
>>>>> configured for the "performance" governor setting. Then, I noticed that
>>>>> immediately after bootup, the freq was set to 3.5GHz and the governor was
>>>>> set to "performance" as expected. However, without running anything
>>>>> besides "cpufreq-info", I noticed that after about 30 secs or so, the
>>>>> governor setting unexpectedly changed to "ondemand" and the freq setting
>>>>> dropped to 1.2 GHz. If I subsequently restart cpufrequtils using "sudo
>>>>> /etc/init.d/cpufrequtils restart", it then seems to stay in the
>>>>> "performance" setting forever.
>>>>>
>>>>> Does anyone know why this setting would change (and/or how I can stop
>>>>> it from doing so)? Looking online, I noticed that there can sometimes be
>>>>> a
>>>>> conflict with "laptop-mode-tools", but this PC is not a laptop and I don't
>>>>> have this package installed.
>>>>>
>>>>> Rob Kossler
>>>>>
>>>>> PC Info
>>>>> Model: HP Z440 Workstation
>>>>> CPU: Xeon E5-1620 v3
>>>>> RAM: 32GB DDR4
>>>>> 10Gb: Intel X520-DA2 (previously used successfully in another PC)
>>>>>
>>>>> UHD Info
>>>>> - 3.8.2 compiled from source, installed via PyBOMBS
>>>>>
>>>>> _______________________________________________
>>>>> 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/20150325/3ad6f6ed/attachment-0001.html>
------------------------------
Message: 22
Date: Wed, 25 Mar 2015 16:49:49 -0400
From: Rob Kossler <[email protected]>
To: Neel Pandeya <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] PC performance optimization
Message-ID:
<CAB__hTSU5ipML6jY7qAmg7DktgCE8sni=u-pin947eu6h13...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
By the way, the popup help for the PCIe Performance Mode settings says
"Configures power and performance options to maximize pcie bandwidth".
This sounds pretty good to me.
Rob
On Wed, Mar 25, 2015 at 4:45 PM, Rob Kossler <[email protected]> wrote:
> I don't know specifically about "ACPI power control/power management". My
> BIOS has the following:
>
> OS Power Options (items with ** described below. First option is the
> current setting)
> - ** Runtime Power Management: Enable/Disable
> - ** Idle Power Savings: Extended/Normal
> - Unique Blink States: Disable/Enable
>
> Additionally, the BIOS contains Performance settings.
>
> Performance Options
> - Intel HyperThreading Technology: Enable/Disable
> - Active CPU Cores For Processor: All cores per processor
> - PCIe Performance Mode: Enable/Disable
> - ** Turbo Mode: Enable/Disable
>
> Note: All items noted with ** indicate items that are unavailable for
> setting or even viewing if the option "PCIe Performance Mode" is Enabled.
> If it is Disabled (which is the default), then I can set all of the **
> items. However, I presently have PCIe Performance Mode Enabled because
> that "seems" to work better.
>
> So,
> 1) Let me know if you have any thoughts on the Power settings. I'm not
> sure if these map to "ACPI power control" or not.
> 2) Let me know if you have any thoughts on the PCIe Performance Mode
> Enable/Disable setting. I would think that we would want this enabled even
> though it is by default disabled. And the fact that the Power options are
> unavailable when this is Enabled makes me think that it effectively
> disables power control / management. But, I don't know that for certain.
>
> Rob
>
> On Wed, Mar 25, 2015 at 4:26 PM, Neel Pandeya <[email protected]>
> wrote:
>
>> Michael's post reminded me, you may also want/need to disable ACPI power
>> control/power management in your BIOS.
>>
>> --Neel
>>
>>
>> On 25 March 2015 at 13:03, Michael West <[email protected]> wrote:
>>
>>> Hi Rob,
>>>
>>> Check for power management utilities and either disable them or make
>>> sure their settings match what you want. What OS are you using?
>>>
>>> Regards,
>>> Michael
>>>
>>> On Wed, Mar 25, 2015 at 12:32 PM, Rob Kossler via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Looking at the CPU specs (Xeon E5-1620 v3), it does appear to support
>>>> EIST. But, I can't find anything in the HP M60 BIOS (v 1.21) related to
>>>> such a setting. BTW, there is a newer bios (1.25A) that I plan to install
>>>> later today....
>>>>
>>>> Regarding the speed settings, I am indeed able to change the MIN speed
>>>> to 3.5GHz. When I reboot now, the CPU setting always reports as 3.5GHz,
>>>> but the governor changes as before. That is, it starts out as
>>>> "performance" and then unexpectedly changes to "ondemand" after 30 secs or
>>>> so. I'm wondering if this is worth worrying about or not. Perhaps as long
>>>> as the CPU stays at 3.5GHz, that is all that matters. Or, perhaps some
>>>> other settings are affected by the "ondemand" governor or whatever is
>>>> triggering the governor setting to change. Not really sure on this???
>>>>
>>>> Rob
>>>>
>>>> On Wed, Mar 25, 2015 at 2:22 PM, Neel Pandeya <[email protected]>
>>>> wrote:
>>>>
>>>>> Hello Rob:
>>>>>
>>>>> Perhaps your CPU has Intel SpeedStep (aka EIST) enabled, and you may
>>>>> need to disable it in the BIOS?? This is the only reason that I can think
>>>>> of at the moment as to why you'd see the behavior that you're seeing.
>>>>> Indeed, the "performance" governor is the governor setting that you want,
>>>>> but I don't understand why it's dynamically changing. I think it's due to
>>>>> Intel SpeedStep.
>>>>>
>>>>> Also, you may need to specify the CPU frequency separately from the
>>>>> governor setting. Set the governor, and then set the CPU frequency to the
>>>>> maximum possible.
>>>>>
>>>>> Please let us know if any of this works/helps.
>>>>>
>>>>> --Neel
>>>>>
>>>>>
>>>>>
>>>>> On 25 March 2015 at 10:48, Rob Kossler via USRP-users <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> I just bought a new PC for use with an X310 and attempted to
>>>>>> configure it according to the instructions here (
>>>>>> http://files.ettus.com/manual/page_usrp_x3x0_config.html).
>>>>>> Subsequently, I tested the configured PC using "benchmark_rate" (2 chan,
>>>>>> full duplex, 100 MS/s). After getting lots of underruns and after doing
>>>>>> some investigation, I noticed something strange. My CPU speed as
>>>>>> reported
>>>>>> by "cpufreq-info" was at 1.2 GHz rather than 3.5 GHz.
>>>>>>
>>>>>> I double-checked that the file "/etc/init.d/cpufrequtils" was
>>>>>> configured for the "performance" governor setting. Then, I noticed that
>>>>>> immediately after bootup, the freq was set to 3.5GHz and the governor was
>>>>>> set to "performance" as expected. However, without running anything
>>>>>> besides "cpufreq-info", I noticed that after about 30 secs or so, the
>>>>>> governor setting unexpectedly changed to "ondemand" and the freq setting
>>>>>> dropped to 1.2 GHz. If I subsequently restart cpufrequtils using "sudo
>>>>>> /etc/init.d/cpufrequtils restart", it then seems to stay in the
>>>>>> "performance" setting forever.
>>>>>>
>>>>>> Does anyone know why this setting would change (and/or how I can stop
>>>>>> it from doing so)? Looking online, I noticed that there can sometimes
>>>>>> be a
>>>>>> conflict with "laptop-mode-tools", but this PC is not a laptop and I
>>>>>> don't
>>>>>> have this package installed.
>>>>>>
>>>>>> Rob Kossler
>>>>>>
>>>>>> PC Info
>>>>>> Model: HP Z440 Workstation
>>>>>> CPU: Xeon E5-1620 v3
>>>>>> RAM: 32GB DDR4
>>>>>> 10Gb: Intel X520-DA2 (previously used successfully in another PC)
>>>>>>
>>>>>> UHD Info
>>>>>> - 3.8.2 compiled from source, installed via PyBOMBS
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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/20150325/8e66c617/attachment-0001.html>
------------------------------
Message: 23
Date: Wed, 25 Mar 2015 21:59:04 +0100
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] zpu-elf-gcc not compiling correctly
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Aaron,
that's very strange. My guess is that some some of the programs in the
folder that contain zpu-elf-gcc conflict with your shell's built-in
names or with "ls" as a program name...
I assume you did something like
export PATH=$PATH:/path/to/zpu-elf-gcc/containing/folder
try
export PATH=/path/to/zpu-elf-gcc/containing/folder:$PATH
instead.
If that doesn't help, I'd recommend manually making symbolic links from
the zpu-elf-gcc executable into a typical executable directory, ie.
sudo ln -s /path/to/zpu-elf-gcc/containing/folder/zpu-elf-gcc /usr/local/bin
(make sure /usr/local/bin or whatever directory you use is in $PATH).
Greetings,
Marcus
PS: I simply assumed this was an unixoid, or essentially linux. Am I
right? If I am, which distribution are you using?
On 03/23/2015 05:55 PM, Aaron Henderson via USRP-users wrote:
> I am trying to make my usrp2 firmware for an N210 device, and when I run the
> cmake command, the terminal replies that i need to add zpu-elf-gcc to my
> $PATH.
>
> I run the command to add the path and I lose functionality of my ls command.
>
> Has this happened to anyone else?
>
> Aaron
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 24
Date: Wed, 25 Mar 2015 22:03:29 +0100
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Sending samples to USRP2 using
"tx_samples_from_file"
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Dear Awantha,
sorry, your mail slipped through my inbox -- it got sorted away as spam;
did you use the "reply" functionality of your email client?
How do you connect your USRP to your oscilloscope? A mistake that
happened to me several times was not using the SMA connector on the
front that was actually connected to the transmitting RF connector on
the daughterboard, so I'd like to as you to make sure you use the right
port.
As a side note, the gain setting is meaningless, LFTX doesn't have
adjustable gain.
Best regards,
Marcus M?ller
On 03/19/2015 05:59 PM, Awantha Jayasiri via USRP-users wrote:
> Mi Marcus,
> Sorry. My bad. I was thinking N200 is USRP2.
> The command as follows (freq is 1MHz):
> ./tx_samples_from_file --type=short --rate=200e3 --freq=1e6 --gain=0
> --repeat --file=/home/user1/usrp_codes/sine_out.bin
>
> However, still I can't see any signal from oscilloscope.
> Thanks
> Awantha
>
>
> _______________________________________________
> 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/20150325/5ab8d0e8/attachment-0001.html>
------------------------------
Message: 25
Date: Wed, 25 Mar 2015 14:44:38 -0700
From: Michael West <[email protected]>
To: Rob Kossler <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] PC performance optimization
Message-ID:
<cam4xkrq3zvopoqom+7qw_pxe0etsws8xuprqz4635gaotd1...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
It looks like /etc/init.d/ondemand will set the governor to ondemand and is
called whenever it is booted into multi-user mode. There are 2 options as
I see it:
1) Disable the script by changing S99ondemand to s99ondemand in the
/etc/rc*.d directories.
2) Edit /etc/init.d/ondemand to set the governor to "performance".
(Looks like we need to update our documentation either way.)
Regards,
Michael
On Wed, Mar 25, 2015 at 1:49 PM, Rob Kossler via USRP-users <
[email protected]> wrote:
> By the way, the popup help for the PCIe Performance Mode settings says
> "Configures power and performance options to maximize pcie bandwidth".
> This sounds pretty good to me.
>
> Rob
>
> On Wed, Mar 25, 2015 at 4:45 PM, Rob Kossler <[email protected]> wrote:
>
>> I don't know specifically about "ACPI power control/power management".
>> My BIOS has the following:
>>
>> OS Power Options (items with ** described below. First option is the
>> current setting)
>> - ** Runtime Power Management: Enable/Disable
>> - ** Idle Power Savings: Extended/Normal
>> - Unique Blink States: Disable/Enable
>>
>> Additionally, the BIOS contains Performance settings.
>>
>> Performance Options
>> - Intel HyperThreading Technology: Enable/Disable
>> - Active CPU Cores For Processor: All cores per processor
>> - PCIe Performance Mode: Enable/Disable
>> - ** Turbo Mode: Enable/Disable
>>
>> Note: All items noted with ** indicate items that are unavailable for
>> setting or even viewing if the option "PCIe Performance Mode" is Enabled.
>> If it is Disabled (which is the default), then I can set all of the **
>> items. However, I presently have PCIe Performance Mode Enabled because
>> that "seems" to work better.
>>
>> So,
>> 1) Let me know if you have any thoughts on the Power settings. I'm not
>> sure if these map to "ACPI power control" or not.
>> 2) Let me know if you have any thoughts on the PCIe Performance Mode
>> Enable/Disable setting. I would think that we would want this enabled even
>> though it is by default disabled. And the fact that the Power options are
>> unavailable when this is Enabled makes me think that it effectively
>> disables power control / management. But, I don't know that for certain.
>>
>> Rob
>>
>> On Wed, Mar 25, 2015 at 4:26 PM, Neel Pandeya <[email protected]>
>> wrote:
>>
>>> Michael's post reminded me, you may also want/need to disable ACPI power
>>> control/power management in your BIOS.
>>>
>>> --Neel
>>>
>>>
>>> On 25 March 2015 at 13:03, Michael West <[email protected]> wrote:
>>>
>>>> Hi Rob,
>>>>
>>>> Check for power management utilities and either disable them or make
>>>> sure their settings match what you want. What OS are you using?
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>> On Wed, Mar 25, 2015 at 12:32 PM, Rob Kossler via USRP-users <
>>>> [email protected]> wrote:
>>>>
>>>>> Looking at the CPU specs (Xeon E5-1620 v3), it does appear to support
>>>>> EIST. But, I can't find anything in the HP M60 BIOS (v 1.21) related to
>>>>> such a setting. BTW, there is a newer bios (1.25A) that I plan to install
>>>>> later today....
>>>>>
>>>>> Regarding the speed settings, I am indeed able to change the MIN speed
>>>>> to 3.5GHz. When I reboot now, the CPU setting always reports as 3.5GHz,
>>>>> but the governor changes as before. That is, it starts out as
>>>>> "performance" and then unexpectedly changes to "ondemand" after 30 secs or
>>>>> so. I'm wondering if this is worth worrying about or not. Perhaps as
>>>>> long
>>>>> as the CPU stays at 3.5GHz, that is all that matters. Or, perhaps some
>>>>> other settings are affected by the "ondemand" governor or whatever is
>>>>> triggering the governor setting to change. Not really sure on this???
>>>>>
>>>>> Rob
>>>>>
>>>>> On Wed, Mar 25, 2015 at 2:22 PM, Neel Pandeya <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Hello Rob:
>>>>>>
>>>>>> Perhaps your CPU has Intel SpeedStep (aka EIST) enabled, and you may
>>>>>> need to disable it in the BIOS?? This is the only reason that I can think
>>>>>> of at the moment as to why you'd see the behavior that you're seeing.
>>>>>> Indeed, the "performance" governor is the governor setting that you want,
>>>>>> but I don't understand why it's dynamically changing. I think it's due to
>>>>>> Intel SpeedStep.
>>>>>>
>>>>>> Also, you may need to specify the CPU frequency separately from the
>>>>>> governor setting. Set the governor, and then set the CPU frequency to the
>>>>>> maximum possible.
>>>>>>
>>>>>> Please let us know if any of this works/helps.
>>>>>>
>>>>>> --Neel
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 25 March 2015 at 10:48, Rob Kossler via USRP-users <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> I just bought a new PC for use with an X310 and attempted to
>>>>>>> configure it according to the instructions here (
>>>>>>> http://files.ettus.com/manual/page_usrp_x3x0_config.html).
>>>>>>> Subsequently, I tested the configured PC using "benchmark_rate" (2 chan,
>>>>>>> full duplex, 100 MS/s). After getting lots of underruns and after doing
>>>>>>> some investigation, I noticed something strange. My CPU speed as
>>>>>>> reported
>>>>>>> by "cpufreq-info" was at 1.2 GHz rather than 3.5 GHz.
>>>>>>>
>>>>>>> I double-checked that the file "/etc/init.d/cpufrequtils" was
>>>>>>> configured for the "performance" governor setting. Then, I noticed that
>>>>>>> immediately after bootup, the freq was set to 3.5GHz and the governor
>>>>>>> was
>>>>>>> set to "performance" as expected. However, without running anything
>>>>>>> besides "cpufreq-info", I noticed that after about 30 secs or so, the
>>>>>>> governor setting unexpectedly changed to "ondemand" and the freq setting
>>>>>>> dropped to 1.2 GHz. If I subsequently restart cpufrequtils using "sudo
>>>>>>> /etc/init.d/cpufrequtils restart", it then seems to stay in the
>>>>>>> "performance" setting forever.
>>>>>>>
>>>>>>> Does anyone know why this setting would change (and/or how I can
>>>>>>> stop it from doing so)? Looking online, I noticed that there can
>>>>>>> sometimes
>>>>>>> be a conflict with "laptop-mode-tools", but this PC is not a laptop and
>>>>>>> I
>>>>>>> don't have this package installed.
>>>>>>>
>>>>>>> Rob Kossler
>>>>>>>
>>>>>>> PC Info
>>>>>>> Model: HP Z440 Workstation
>>>>>>> CPU: Xeon E5-1620 v3
>>>>>>> RAM: 32GB DDR4
>>>>>>> 10Gb: Intel X520-DA2 (previously used successfully in another PC)
>>>>>>>
>>>>>>> UHD Info
>>>>>>> - 3.8.2 compiled from source, installed via PyBOMBS
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>
>>>>>
>>>>
>>>
>>
>
> _______________________________________________
> 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/20150325/da9e740e/attachment-0001.html>
------------------------------
Message: 26
Date: Wed, 25 Mar 2015 16:26:44 -0700
From: Michael West <[email protected]>
To: Joel Bratin <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] 4 Channel Synchronization with 2 X-300s
Message-ID:
<cam4xkrpbpe_znpgez79nqv875j4nrdhuiqqzwumccijofsw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Joel,
So, here is what is going on. When using multiple X300s, they need to have
the same time set on both. If not, there will be all kinds of timing
issues. Supplying a common external reference and PPS and using
set_time_unknown_pps() is the best way to synchronize the times on the
devices.
The benchmark_rate example does not do this, so the default reference and
PPS are used and the times on the X300s are different. The RX rate test
results in a timeout when specifying channels on the second device because
it sets the start time for the streaming based on the time retrieved from
the first device. You can modify the example to add lines to set the clock
and time sources to external and call set_time_unknown_pps() and it should
work fine.
Hope this helps clear things up.
Regards,
Michael
On Tue, Mar 24, 2015 at 2:08 PM, Joel Bratin <[email protected]> wrote:
> Hi Michael,
>
>
>
> We are using UHD 3.8.2. We tried it on Windows, Mac OS and Linux (Fedora)
> and received the same problem.
>
>
> Steps to reproduce the problem:
>
> 1. X300 #1 with IP address 192.168.40.2
>
> 2. X300 #2 with IP Address 192.168.140.2
>
> 3. Connect each X300 to its own interface on our Intel X520-DA2
>
> 4. Reboot each X300
>
> 5. Run benchmark_rate.exe --args ?addr0=192.168.140.2,
> addr1=192.168.40.2? ?rx_rate 625000 ?channels ?2,3
>
>
>
> When running we receive ERROR_CODE_TIMEOUT
>
>
>
> We managed to find a workaround but we?re not entirely sure why it works.
>
> In our own application we used *set_time_source(?external?)* and
> *set_clock_source(?external?)*. We connected an external clock and PPS to
> both X300s.
>
> We called *set_time_unknown_pps(uhd::time_spec_t(0.0))*
>
>
>
> We stopped seeing the ERROR_CODE_TIMEOUT while streaming.
>
> Furthermore, when we returned back to benchmark_rate.exe we found that we
> stopped getting the ERROR_CODE_TIMEOUT. The ERROR_CODE_TIMEOUT disappeared
> until we shut off one of the X300s and turned it back on.
>
>
>
> It seems like our application kicked the X300s into a working state but
> we?re not sure why. Do you have any idea what could?ve fixed our problem?
>
>
>
> Benchmark_rate doesn?t set the *time_*source or *?clock_*source so we
> assume it automatically uses an ?internal? *clock_source* and ?internal?
> *time_source*. Should we expect to see ERROR_CODE_TIMEOUT if we?re not
> using an external clock/PPS? Is there a command that we called that might
> be missing in benchmark_rate?
>
>
>
> Thanks,
>
> Joel Bratin
>
>
>
> *From:* Michael West [mailto:[email protected]]
> *Sent:* Tuesday, March 24, 2015 4:09 PM
>
> *To:* Joel Bratin
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] 4 Channel Synchronization with 2 X-300s
>
>
>
> Hi Joel,
>
>
>
> It should work the way you are using it. Can you tell me what version of
> UHD you are using so I can try to reproduce it and look into it further for
> you?
>
>
>
> Thanks,
>
> Michael
>
>
>
> On Tue, Mar 24, 2015 at 7:48 AM, Joel Bratin <[email protected]>
> wrote:
>
> Hi Michael,
>
>
>
> The two network interfaces are on different subnets and both have
> 255.255.255.0 subnet masks.
>
>
>
> I am able to stream from each channel independently so I know that I can
> connect to both X300s.
>
>
>
> I don?t understand why benchmark_rate.exe --args "addr0=192.168.140.2,
> addr1=192.168.40.2" --rx_rate 625000 --channels"0,1" works perfectly but
> benchmark_rate.exe --args "addr0=192.168.40.2, addr1=192.168.140.2"
> --rx_rate 625000 --channels"2,3" gives me the ERROR_CODE_TIMEOUT error.
>
> For some reason changing the values of addr0 and addr1 causes an issue.
>
>
>
> Does something happen in uhd that it treats the devices on addr0 and addr1
> differently? Does it matter which one I declare as addr0 and which one I
> declare as addr1?
>
>
>
> Thanks,
>
> Joel Bratin
>
>
>
> *From:* Michael West [mailto:[email protected]]
> *Sent:* Monday, March 23, 2015 5:32 PM
> *To:* Joel Bratin
> *Cc:* [email protected]
>
>
> *Subject:* Re: [USRP-users] 4 Channel Synchronization with 2 X-300s
>
>
>
> Hi Joel,
>
> This looks like it could be a network interface configuration issue.
> Check to make sure the two network interfaces on the host computer are on
> different subnets and the subnet masks are set correctly (should be
> 255.255.255.0).
>
> Regards,
>
> Michael
>
>
>
> On Mon, Mar 23, 2015 at 1:19 PM, Joel Bratin via USRP-users <
> [email protected]> wrote:
>
> Hi,
>
> My setup from last week keeps running into the same problem.
>
> When receiving from the rx_streamer I get the ERROR_CODE_TIMEOUT error.
>
> I tried debugging my setup with benchmark_rate and noticed that I get this
> error when trying to stream from channels "2" and "3" regardless of which
> X300 was designated as the addr1.
>
> For example, the following commands lead to ERROR_CODE_TIMEOUTs.
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"0,2"
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"0,3"
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"1,2"
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"1,3"
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"1,2"
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"2,3"
> benchmark_rate.exe --args "addr0=192.168.40.2, addr1=192.168.140.2"
> --rx_rate 625000 --channels"2,3" <-- notice the addr0/addr1 swap doesn't
> help
>
> The following commands are successful:
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"0"
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"1"
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"2"
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"3"
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"0,1"
> benchmark_rate.exe --args "addr0=192.168.40.2, addr1=192.168.140.2"
> --rx_rate 625000 --channels"0,1" <-- addr0/addr1 swap still works
>
> I got the same error last week and it seemed to disappear on its own but
> now it's happening again.
>
> It doesn't look like a hardware issue because the following 2 commands do
> the same thing (stream both channels on 192.168.140.2) but give the
> opposite results
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"0,1" --> works
> benchmark_rate.exe --args "addr0=192.168.40.2, addr1=192.168.140.2"
> --rx_rate 625000 --channels"2,3" --> FAILS
>
> Any insight into this problem would be greatly appreciated.
>
> Thanks,
> Joel Bratin
>
> -----Original Message-----
> From: USRP-users [mailto:[email protected]] On Behalf Of
> Daniele Nicolodi via USRP-users
> Sent: Friday, March 20, 2015 1:14 PM
> To: [email protected]
> Subject: Re: [USRP-users] 4 Channel Synchronization with 2 X-300s
>
> On 20/03/15 17:57, Marcus D. Leech via USRP-users wrote:
> > On 03/20/2015 12:51 PM, Daniele Nicolodi via USRP-users wrote:
> >> A completely different matter is the PPS generation. If you need a
> >> PPS to synchronize multiple instruments you can use a PPS generated
> >> from a whatever oscillator (and much probably you don't even need
> >> this, but simply a trigger signal).
> >>
> >> If what you need is to align a local time scale to a well known time
> >> scale, well, you need to connect to that time scale somehow. How you
> >> do that, depends on what are your synchronization requirements. A GPS
> >> receiver gives you good synchronization to the GPS time, which can be
> >> related to the UTC time (or assumed equal to the UTC time, for most
> >> applications).
> >
> > Thanks, Daniele.
> >
> > I was mostly idly curious about the existence of less-expensive
> > devices based on a 10MHz OCXO that also produce a 1PPS signal. I have a
> bunch of
> > 10MHz OCXOs myself, and while *I* could easily whip up something
> > that produces a 1PPS pulse in parallel to the 10MHz output, I was
> curious about
> > commercial "off the shelf" devices that did this, and that weren't
> > necessarily GPSDOs.
>
> I still don't understand why you need a PPS. Is it to synchronize multiple
> devices to a common time scale? If that is the case, simply generating an
> unreferenced PPS (as the one you could derive from different oscillators)
> is definitely not a solution. In this case what you need is a PPS generator
> and distributor (a device with multiple phase aligned PPS outputs). Such a
> device may or may not include an oscillator (you may need to plug an
> external one). No idea of the price range for such a device, but it is
> going to depend a lot on your accuracy and stability requirements.
>
> Cheers,
> Daniele
>
>
> _______________________________________________
> 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/20150325/27e9af70/attachment-0001.html>
------------------------------
Message: 27
Date: Thu, 26 Mar 2015 11:54:00 +0500
From: Rana Arslan Ahmad <[email protected]>
To: Marcus M?ller <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] Pulse width Transmission on sdr
Message-ID:
<caaj55cb+aww9amc_uxfjbu9vn0xnc0xxlfrmrvjni9uks-r...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
right.
You mean I should avoid USRP Embedded E-series for digital signals
processing like waveform generation. As far as I know, that this series is
made for standalone applications like Mobile radios, GSM(OpenBTS) and Drone
etc. And I cannot directly code via MATLAB toolbox.
Well if I want to generate desired waveform through Gnuradio in Embedded
series?
#exclude MATLAB
Please guide me.
On Wed, Mar 25, 2015 at 10:51 PM, Marcus M?ller <[email protected]>
wrote:
> One thing you should note is that I personally don't recommend using the
> Embedded E-series devices for prototyping of signal waveforms. These
> devices integrate an embedded linux machine with USRP hardware, which makes
> it very easy to develop applications that require standalone operation, for
> example remote sensors, base stations, beacons, etc.
>
> However, if you want to prototype your RF application, it's general
> advisable to not start with the embedded device, but with one of the
> peripheral USRPs (B2x0, N2x0, X3x0), since these allow execution of your
> SDR software on a real PC, and take the burden of developing and debugging
> for/on an embedded platform of your shoulders. The E310 and E110 are
> specialized pieces of embedded hardware, which, for example, means that you
> can't run matlab on it. Depending on your toolboxes, you might be able to
> export code that you can compile for these platforms, but that requires
> that you have the time to get to know a bit about software development.
>
> If you use a peripheral USRP and develop your software on a linux PC, once
> you have a proof of concept, transferring the software to the embedded
> device will usually be relatively easy -- the UHD driver running on the
> embedded devices has exactly the same interface as UHD running on a full
> PC, talking to a peripheral USRP, over network, PCIe or USB, and after all,
> it's running a normal linux kernel.
>
> A typical GNU Radio based workflow would be to design one's flow graph in
> the GNU Radio companion interface graphically, if necessary writing one's
> own signal processing blocks in Python or C++, and verifying operation on
> the PC with a peripheral USRP. When everything works, one would simply take
> the resulting code, and compile (only necessary if C++ was used) it for the
> E310/E110, and copy it to the embedded device.
>
> Greetings,
> Marcus
>
>
>
> On 03/25/2015 06:36 PM, Rana Arslan Ahmad via USRP-users wrote:
>
> ok and you're right, at the moment looking forward to work on E110 for
> time being or maybe order E310 soon.
> I don't have much experience of Gnuradio programming but I've done a lot
> of digital communications labs via MATLAB.
>
> WBX daughterboard.
>
> On Wed, Mar 25, 2015 at 10:29 AM, Neel Pandeya <[email protected]>
> wrote:
>
>> Please keep this conversation on the mailing list.
>>
>> If I recall, you're using E110, right?
>> Which daughterboard?
>>
>> What kind of modulation?
>>
>> --Neel
>>
>>
>>
>> On 25 March 2015 at 10:19, Rana Arslan Ahmad <[email protected]> wrote:
>>
>>> I am using USRP embedded series. Actually I want to transmit a pulse
>>> train. Probably 60% duty cycle with respective modulation.
>>> Yes, this should be possible using UHD directly or with GNU Radio.
>>>
>>> Which USRP and daughterboard are you using?
>>>
>>> Could you provide more details about what you want to do? What kind of
>>> pulse? 10 ms, 50% duty cycle? What kind of modulation?
>>>
>>> --Neel
>>>
>>>
>>>
>>> On 25 March 2015 at 09:53, Rana Arslan Ahmad via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Hey all,
>>>>
>>>> I want to generate a pulse of 10ms and then modulate it and transmit on
>>>> 1 GHz.
>>>>
>>>> Is it possible with Gnuradio or any other framework of USRP??
>>>>
>>>> Thanks
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>
>>
>
>
> _______________________________________________
> 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/20150326/47219b4a/attachment-0001.html>
------------------------------
Message: 28
Date: Thu, 26 Mar 2015 09:30:19 +0100
From: Marcus M?ller <[email protected]>
To: Rana Arslan Ahmad <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] Pulse width Transmission on sdr
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Rana,
On 03/26/2015 07:54 AM, Rana Arslan Ahmad wrote:
> right.
>
> You mean I should avoid USRP Embedded E-series for digital signals
> processing like waveform generation.
Not generally, but if you don't need standalone operation, I see no
sense in spending additional money, and mostly, in taking the route
where you have to do both, DSP and embedded development.
> As far as I know, that this series is made for standalone applications
> like Mobile radios, GSM(OpenBTS) and Drone etc. And I cannot directly
> code via MATLAB toolbox.
>
> Well if I want to generate desired waveform through Gnuradio in
> Embedded series?
> #exclude MATLAB
You can of course simply compile GNU Radio for both you PC and the
E-device, and develop stuff on your PC, and then copy it over. You'd
still have the "cross-compile" and the "copying it over" steps
additionally to the DSP development effort. The E310 doesn't have a
built-in display controller, and the E110's processor is not optimized
for graphical workload, so the typical workflow for developing GNU Radio
applications and testing them with a click of a button or the execution
of a command won't work, as you can't display the data the device is
currently transmitting (or that displaying consumes a significant amount
of CPU power, making it harder to implement working algorithms).
> Please guide me.
A guide starts by asking where someone wants to go. So far, I only know
you want to transmit a single pulse -- that surely isn't your
application's whole purpose.
For me, the basic decision is clear: If you don't need to do it in a
standalone embedded device, don't by an E-series embedded device.
If you need to do it on an embedded device, buy an E-series device;
typically, you'd also buy an B2x0, N2x0 or even an X3x0 to develop your
application on a PC, before moving it to the embedded device, as it will
be easier to develop and test algorithms on a proper PC.
Greetings,
Marcus
------------------------------
Message: 29
Date: Thu, 26 Mar 2015 13:47:22 +0500
From: Rana Arslan Ahmad <[email protected]>
To: Marcus M?ller <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] Pulse width Transmission on sdr
Message-ID:
<caaj55cb5_e5qc1sdgscqkdajihxj48tooor0wg84mkftbne...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks for your detailed guidance.
Can I run proposed FM application like FM receiver on Embedded E-series??
#excluding desired waveform generation or avoiding in this series
#A standalone FM Receive
On Thu, Mar 26, 2015 at 1:30 PM, Marcus M?ller <[email protected]>
wrote:
> Hi Rana,
>
> On 03/26/2015 07:54 AM, Rana Arslan Ahmad wrote:
> > right.
> >
> > You mean I should avoid USRP Embedded E-series for digital signals
> > processing like waveform generation.
> Not generally, but if you don't need standalone operation, I see no
> sense in spending additional money, and mostly, in taking the route
> where you have to do both, DSP and embedded development.
> > As far as I know, that this series is made for standalone applications
> > like Mobile radios, GSM(OpenBTS) and Drone etc. And I cannot directly
> > code via MATLAB toolbox.
> >
> > Well if I want to generate desired waveform through Gnuradio in
> > Embedded series?
> > #exclude MATLAB
> You can of course simply compile GNU Radio for both you PC and the
> E-device, and develop stuff on your PC, and then copy it over. You'd
> still have the "cross-compile" and the "copying it over" steps
> additionally to the DSP development effort. The E310 doesn't have a
> built-in display controller, and the E110's processor is not optimized
> for graphical workload, so the typical workflow for developing GNU Radio
> applications and testing them with a click of a button or the execution
> of a command won't work, as you can't display the data the device is
> currently transmitting (or that displaying consumes a significant amount
> of CPU power, making it harder to implement working algorithms).
> > Please guide me.
> A guide starts by asking where someone wants to go. So far, I only know
> you want to transmit a single pulse -- that surely isn't your
> application's whole purpose.
>
> For me, the basic decision is clear: If you don't need to do it in a
> standalone embedded device, don't by an E-series embedded device.
> If you need to do it on an embedded device, buy an E-series device;
> typically, you'd also buy an B2x0, N2x0 or even an X3x0 to develop your
> application on a PC, before moving it to the embedded device, as it will
> be easier to develop and test algorithms on a proper PC.
>
> Greetings,
> Marcus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150326/12d828d6/attachment-0001.html>
------------------------------
Message: 30
Date: Thu, 26 Mar 2015 09:49:48 +0100
From: Marcus M?ller <[email protected]>
To: Rana Arslan Ahmad <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] Pulse width Transmission on sdr
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Rana,
yes, you can do whatever the CPU is up to on the E-series devices. It's
really just easier to develop on a PC. Also, PCs have much more powerful
CPUs, so you can typically process higher bandwidths, but that of course
depends on the things you do. I can't help you estimate your own
application's CPU needs.
Greetings,
Marcus
On 03/26/2015 09:47 AM, Rana Arslan Ahmad wrote:
> Thanks for your detailed guidance.
>
> Can I run proposed FM application like FM receiver on Embedded E-series??
> #excluding desired waveform generation or avoiding in this series
> #A standalone FM Receive
>
>
> On Thu, Mar 26, 2015 at 1:30 PM, Marcus M?ller
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi Rana,
>
> On 03/26/2015 07:54 AM, Rana Arslan Ahmad wrote:
> > right.
> >
> > You mean I should avoid USRP Embedded E-series for digital signals
> > processing like waveform generation.
> Not generally, but if you don't need standalone operation, I see no
> sense in spending additional money, and mostly, in taking the route
> where you have to do both, DSP and embedded development.
> > As far as I know, that this series is made for standalone applications
> > like Mobile radios, GSM(OpenBTS) and Drone etc. And I cannot
> directly
> > code via MATLAB toolbox.
> >
> > Well if I want to generate desired waveform through Gnuradio in
> > Embedded series?
> > #exclude MATLAB
> You can of course simply compile GNU Radio for both you PC and the
> E-device, and develop stuff on your PC, and then copy it over. You'd
> still have the "cross-compile" and the "copying it over" steps
> additionally to the DSP development effort. The E310 doesn't have a
> built-in display controller, and the E110's processor is not optimized
> for graphical workload, so the typical workflow for developing GNU
> Radio
> applications and testing them with a click of a button or the
> execution
> of a command won't work, as you can't display the data the device is
> currently transmitting (or that displaying consumes a significant
> amount
> of CPU power, making it harder to implement working algorithms).
> > Please guide me.
> A guide starts by asking where someone wants to go. So far, I only
> know
> you want to transmit a single pulse -- that surely isn't your
> application's whole purpose.
>
> For me, the basic decision is clear: If you don't need to do it in a
> standalone embedded device, don't by an E-series embedded device.
> If you need to do it on an embedded device, buy an E-series device;
> typically, you'd also buy an B2x0, N2x0 or even an X3x0 to develop
> your
> application on a PC, before moving it to the embedded device, as
> it will
> be easier to develop and test algorithms on a proper PC.
>
> Greetings,
> Marcus
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150326/88ea2cae/attachment-0001.html>
------------------------------
Message: 31
Date: Thu, 26 Mar 2015 13:31:03 +0100
From: Anselm Karl <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Errors while building fpga RFNOC X300 image
Message-ID:
<cakcs5r3q0kob27wmnqsu_xtopk5dy5uwln8vy7t3cwijexo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi everyone,
i am trying to make some custom rfnoc blocks for the x300. While building
the images the process stops with an error.
Here is what i do:
(i use ise 14.7 on ubuntu 14.04lts, my fpga sources are a month old)
- Design the custom logic in Xilinx System Generator and generate a
ngc-netlist from it.
- Put the files from system generator (my_logic.v my_logic.ngc) into
/lib/rfnoc (my_logic.v is a verilog black box - just the interface no logic)
- copy and edit noc_block_axi_fifo_loopback.v so that the module my_logic
gets instantiated. (i rename the file to noc_block_my_block.v and the
module to noc_block_my_block)
- add the extra files to .../rfnoc/makefile.scrs
- edit /top/x300/rfnoc_ce_auto_inst_x300.v so that the module
noc_block_my_block gets instantiated instead of noc_block_fft
- build
Here is what happens:
-Theres is a syntax error concerning rfnoc_ce_auto_inst_x300.v line 10
(This may be part of the problem, but i get this error when building
without my customizations too. In this case and the building works in spite
of the error)
-The error that makes the compiler quit is, that it cant find the module
noc_block_my_block
(In the build.log i see, that the compiler looks at the file
noc_block_my_block, but later does NOT put the module noc_block_my_block
into the build library. Because of my fix - see below - i am sure that my
code is okay. I dont see any more errors neither.)
Here is my (not very nice) fix:
i call the module noc_block_my_block like an existing noc_block (for
example noc_block_fir_filter) and it works. The file name doesnt matter as
long as it is in makefiles.scrs .
The building works and the customized block works to. UHD recognizes it as
an fifo, because of the ID, i guess.
>From build.log:
ERROR:HDLCompiler:806 -
"/home/randy/x300_devel/formail/fpga-src/usrp3/top/x300/rfnoc_ce_auto_inst_x3
00.v" Line 10: Syntax error near "generate".
=> That is the syntax error, which always get (even without customizations)
INFO:HDLCompiler:1845 - Analyzing Verilog file
"/home/randy/x300_devel/formail/fpga-src/usrp3/lib/rfnoc/noc_block_my_block.v
" into library work
=> compiler analyzes the file
Analyzing Verilog file
"/home/randy/x300_devel/formail/fpga-src/usrp3/lib/rfnoc/noc_block_addsub.v"
into library work
Parsing module <noc_block_addsub>.
=> i dont get this line for my_block :-(
ERROR:HDLCompiler:1654 -
"/home/randy/x300_devel/formail/fpga-src/usrp3/top/x300/rfnoc_ce_auto_inst_x300.v"
Line 27: Instantiating <inst_noc_block_fir_filter> from unknown module
<noc_block_my_block>
Module x300_core remains a blackbox, due to errors in its contents
=> final error, compiler doesnt know the module noc_bloc_my_block
Please help me to get rid of my ugly fix!
--
Mit freundlichen Gr??en
*Anselm Karl*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150326/ba99689a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build.log
Type: text/x-log
Size: 196962 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150326/ba99689a/attachment-0001.log>
------------------------------
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 55, Issue 26
******************************************
