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: Asymmetry in achievable TX/RX rates (Claudio Cicconetti)
2. Re: Cannot se sent out signal in oscilloscope (Steven Knudsen)
3. Re: Cannot se sent out signal in oscilloscope (Julian Arnold)
4. RuntimeError: basic_string::_M_construct null not valid when
using RFNoC:Radio (Sebastian Mueller)
5. Re: RuntimeError: basic_string::_M_construct null not valid
when using RFNoC:Radio (Jason Matusiak)
6. Re: Asymmetry in achievable TX/RX rates (Stefano Bettelli)
7. Re: No GPSDO found message (Michael West)
8. B205mini power usage (Jason Matusiak)
9. Re: B205mini power usage (Marcus D. Leech)
10. Re: R: header file msg.hpp in the uhd release (Martin Braun)
11. Increase number of tx burst send timed commands in UHD
([email protected])
12. Install uhd on Raspberry Pi 3 (Disco Daniele)
13. sorry to duplicate post (Disco Daniele)
14. Re: Install uhd on Raspberry Pi 3 (Martin Braun)
15. USRP B200 (Rohit Dilip)
16. Re: USRP B200 (Martin Braun)
17. Re: USRP B200 (Martin Braun)
18. Re: USRP B200 (Rohit Dilip)
19. Re: USRP B200 (Martin Braun)
20. Re: USRP B200 (Rohit Dilip)
21. Re: Asymmetry in achievable TX/RX rates (Martin Braun)
22. Re: USRP B200 (Martin Braun)
23. Re: USRP B200 (Rohit Dilip)
24. Re: The difference between the samp_rate in GNU Radio and
Nyquist rate (Martin Braun)
25. Re: The difference between the samp_rate in GNU Radio and
Nyquist rate (Nate Temple)
26. Re: Wireless data transfer (do ber)
27. on-off keying modulation and demodulation (Yutong Liu)
28. X310-PCIe connection in Linux (do ber)
29. R: Install uhd on Raspberry Pi 3 (Crozzoli Maurizio)
30. Re: Wireless data transfer (Julian Arnold)
31. Re: RuntimeError: basic_string::_M_construct null not valid
when using RFNoC:Radio (Sebastian Mueller)
32. X310: who generate overflow and dropped packet messages?
(Paolo Palana)
33. Re: on-off keying modulation and demodulation (Julian Arnold)
34. Re: X310: who generate overflow and dropped packet messages?
(Stefano Bettelli)
35. Re: B205mini power usage (Jason Matusiak)
36. Re: RuntimeError: basic_string::_M_construct null not valid
when using RFNoC:Radio (Jason Matusiak)
37. Re: X310-PCIe connection in Linux (Marcus D. Leech)
38. Re: Wireless data transfer (Marcus M?ller)
39. Re: USRP B200 (Marcus M?ller)
----------------------------------------------------------------------
Message: 1
Date: Wed, 1 Mar 2017 18:04:40 +0100
From: Claudio Cicconetti <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Dear Stefano,
Fascinating issue.
I tried your example with a slightly different environment (X300, single
10 GbE connection to host, single WBX-120, uhd-3.10.1.1) but the result
is the *same*.
Basically the use case is:
- tx rate = 1 MS/s
- send size = 200 kS
* Scenario1
Sending a total of 1 MS (= 5 calls to send).
A burst ack is received after all sends have been done.
There are a lot of underflows.
* Scenario2
Same as above but sending a total of 2 MS (= 10 calls to send).
No burst ack is received, no underflows.
I tried disabled the time specification in the send() metadata, but the
result is the same. You can find the modified example at:
https://www.dropbox.com/s/m619yrox03cebuj/mybenchmark2.cpp?dl=0
By commenting / uncommenting lines 8 and 9 in the example you can switch
between Scenario1 and Scenario2.
Unfortunately, I could not spot any obvious flaws in your example.
Best regards,
Claudio
On 03/01/2017 01:41 PM, Stefano Bettelli wrote:
> Hi Claudio,
>
> -----Original Message-----
>> From: USRP-users [mailto:[email protected]] On Behalf Of
>> Claudio Cicconetti via USRP-users
>> Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates
>> Hello Stefano,
>> Do you mind sharing the source code of your modified benchmark_rate?
>
> In the spirit of the minimal working example I have prepared a simplified
> code that I attach at the end of this message.
> You have to recompile it to change parameters, because I have stripped out
> all option parsing, but it is a quick thing.
> In the main you can change the args string, the transmit rate, the # of
> channels and the init delay.
> In the send() subthread called b_tx_rate() you can change mainly how many
> samples per channel you send with each individual send().
> This benchmark runs till "target" (global variable) samples per channel have
> been sent, or till the send() returns 0.
>
> Compile it with the following command line:
> g++ -std=c++14 -Wall -Wextra -O3 -s -o mybenchmark mybenchmark.cpp -luhd
> -lpthread -lboost_system
>
> I have an X310 with the XG firmware, and 2 10G cables, and I have tried it in
> the following configurations:
> 1) 2 ch, 1MS/s, 200'000 S/ch, target = 16'000'000 --> OK
> 2) like in 1) but target = 200'000 --> errors
> 3) like in 1) but the # of S/ch is randomly chosen between 200'000 and
> 200'500 --> errors
> 4) same as 1),2) and 3) with only one channel --> same results
>
> Analysing the traffic with Wireshark doesn't show any specific anomaly, nor
> large fluctuations in packet deltas (the transport tends to use UDP packet
> with about 2000B of payload, with a delta of 5-20 microseconds, while one
> packet needs 1ms to be processed by the USRP.
>
> I would be very interested to know whether you get the same results, and
> whether you spot any error in the program workflow.
> Thanks in advance,
> Stefano
>
> --------------- start of mybenchmark.cpp --------- cut here
> -------------------
> #include <uhd/utils/thread_priority.hpp>
> #include <uhd/utils/safe_main.hpp>
> #include <uhd/usrp/multi_usrp.hpp>
> #include <iostream>
> #include <thread>
>
> std::vector<size_t> counts(256, 0); // async message counts
> size_t target { 16000000 }; // total # samples per channel to be TXed
>
> #include <chrono>
> #define NOW std::chrono::high_resolution_clock::now()
> #define DIF ((std::chrono::high_resolution_clock::now()-start).count()/1000)
>
> /***********************************************************************
> * Attempt transmission with multiple send()'s
> **********************************************************************/
> void b_tx_rate(uhd::tx_streamer::sptr tx_stream,
> uhd::time_spec_t start_time, double tx_rate) {
> uhd::tx_metadata_t md;
> md.time_spec = start_time;
> md.has_time_spec = true;
> // const size_t natural_spp = tx_stream->get_max_num_samps();
> const size_t min_spp = 200000;//199600; // samples per channel
> const size_t max_spp = 200000; // samples per channel
> std::cout << "Using " << max_spp << " samples in send()" << std::endl;
> std::vector<char> buff(4 * max_spp); // sc16 is 4 bytes per sample
> const auto num_ch = tx_stream->get_num_channels();
> std::vector<const void *> pts(num_ch, &buff.front());
> auto start { NOW }; size_t accum { 0 };
> while (target > 0) {
> size_t act_spp = min_spp + (double(rand())/RAND_MAX)*(max_spp - min_spp);
> if (act_spp > target) act_spp = target;
> auto rel_time { md.time_spec }; rel_time -= start_time;
> std::cout << " spp " << act_spp << " alsent " << accum
> << " to send " << target << " time spec "
> << rel_time.get_real_secs() << std::endl;
> start = NOW;
> auto n = tx_stream->send(pts, act_spp, md);
> std::cout << "Send call time " << DIF << " sent= " << n << std::endl;
> accum += n; target -= n;
> start = NOW;
> md.time_spec += uhd::time_spec_t::from_ticks(n, tx_rate);
> md.has_time_spec = false;
> if (n == 0) { target = 0; break; /* stop on error */ } }
> md.has_time_spec = false;
> md.end_of_burst = true; // EOB packet
> tx_stream->send(pts, 0, md); }
>
> /***********************************************************************
> * Handle asynchronous messages
> **********************************************************************/
> void b_tx_async(uhd::tx_streamer::sptr tx_stream) {
> uhd::async_metadata_t amd;
> size_t termination = 10; // delayed exit to catch late messages
> while (target > 0 || termination > 0) {
> if (not tx_stream->recv_async_msg(amd)) { // 100ms timeout
> if (target == 0) --termination; continue; }
> ++counts[amd.event_code]; } }
>
> /***********************************************************************
> * Main code + dispatcher
> **********************************************************************/
> int UHD_SAFE_MAIN(int argc, char *argv[]){
> (void)argc; (void)argv;
> // ---------------------------------------------------------------
> std::string args { "addr=192.168.30.2,second_addr=192.168.40.2" };
> std::vector<size_t> tx_channels { 0,1 };
> double init_delay { 0.5 }; // 500mS
> double tx_rate { 1.0e6 };
> // ---------------------------------------------------------------
> uhd::set_thread_priority_safe();
> std::cout << "Creating the usrp device with: " << args << std::endl;
> auto usrp = uhd::usrp::multi_usrp::make(args);
> std::cout << "Using Device: " << usrp->get_pp_string() << std::endl;
> usrp->set_tx_rate(tx_rate);
> //usrp->set_tx_gain(20,0);
> usrp->set_time_unknown_pps(uhd::time_spec_t(0.0));
> uhd::stream_args_t stream_args("sc16", "sc16");
> stream_args.channels = tx_channels;
> auto tx_stream = usrp->get_tx_stream(stream_args);
> std::cout << "\nTX subdev_spec=" << usrp->get_tx_subdev_spec().to_string()
> << "\nTesting tx_rate=" << (usrp->get_tx_rate()/1.0e6) << "MS/s"
> << " chan=" << tx_stream->get_num_channels() << "\n\n";
> auto start_time = usrp->get_time_now() + uhd::time_spec_t(init_delay);
> std::thread tx { b_tx_rate , tx_stream, start_time, tx_rate };
> std::thread as { b_tx_async, tx_stream };
> tx.join(); as.join();
> #define CC(s) std::endl << #s": " << \
> counts[uhd::async_metadata_t::event_code_t::EVENT_CODE_ ## s]
> std::cout << CC(BURST_ACK) << CC(UNDERFLOW) << CC(SEQ_ERROR)
> << CC(TIME_ERROR) << CC(UNDERFLOW_IN_PACKET)
> << CC(SEQ_ERROR_IN_BURST) << CC(USER_PAYLOAD) << std::endl;
> return EXIT_SUCCESS; }
>
------------------------------
Message: 2
Date: Wed, 1 Mar 2017 10:10:21 -0700
From: Steven Knudsen <[email protected]>
To: Carin <[email protected]>
Cc: USRP-users <[email protected]>
Subject: Re: [USRP-users] Cannot se sent out signal in oscilloscope
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi,
Have you tried the Ettus UHD examples?
https://www.ettus.com/content/files/kb/application_note_uhd_examples.pdf
<https://www.ettus.com/content/files/kb/application_note_uhd_examples.pdf>
Don?t forget to turn up the Tx Gain :-)
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen
Der entscheidende Augenblick der menschlichen Entwicklung ist immerw?hrend.
Darum sind die revolution?ren geistigen Bewegungen, welche alles Fr?here f?r
nichtig erkl?ren, im Recht, denn es ist noch nichts geschehen. - Franz Kafka
> On Mar 1, 2017, at 07:17, Carin via USRP-users <[email protected]>
> wrote:
>
>
>
>> Hi,
>>
>> We are working on an SDR solution for satellite communication using your
>> USRP B210 along with GNU Radio Companion. We got stuck on the first step,
>> i.e. transmitting a simple sine-signal created in GNU radio to an
>> oscilloscope. We are however getting some kind of signal, but it doesn?t
>> seem to be related to the frequency and amplitude of the signal source, but
>> rather to the center frequency of the uhd sink.
>>
>> We have also tried following the tutorial "Building a QPSK Transmitter ? on
>> your website but with the same results. Do you have any ideas on what can be
>> wrong?
>>
>> Regards,
>> Carin
> _______________________________________________
> 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/20170301/2d6af833/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 1 Mar 2017 18:14:07 +0100
From: Julian Arnold <[email protected]>
To: Carin <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] Cannot se sent out signal in oscilloscope
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Carin,
maybe you could elaborate a little bit more on you setup?
- How does you flow graph look like?
- What scope are you using (max BW?)
Generally you will not be able to see just the signal you generate using
the signal source block on your scope as the USRP is up-converting that
signal to RF (to the center freq. you set in the UHD USRP Sink block).
Therefore, your scope needs to support a bandwidth that is greater than
the center freq. you chose in order to get a meaningful result.
Hope that helps.
Cheers,
Julian
On 03/01/2017 03:17 PM, Carin via USRP-users wrote:
>
>
>> Hi,
>>
>> We are working on an SDR solution for satellite communication using
>> your USRP B210 along with GNU Radio Companion. We got stuck on the
>> first step, i.e. transmitting a simple sine-signal created in GNU
>> radio to an oscilloscope. We are however getting some kind of signal,
>> but it doesn?t seem to be related to the frequency and amplitude of
>> the signal source, but rather to the center frequency of the uhd sink.
>>
>> We have also tried following the tutorial "Building a QPSK
>> Transmitter ? on your website but with the same results. Do you have
>> any ideas on what can be wrong?
>>
>> Regards,
>> Carin
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
--
Julian Arnold, M.Sc.
Institute for Networked Systems
RWTH Aachen University
Kackertstrasse 9
52072 Aachen
Germany
------------------------------
Message: 4
Date: Wed, 1 Mar 2017 18:14:43 +0100
From: Sebastian Mueller <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] RuntimeError: basic_string::_M_construct null
not valid when using RFNoC:Radio
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi list,
I'm currently trying to get a very basic RFNoC flowgraph running that
looks like this:
[RFNoC: Radio] -> [RFNoC: DDC] -> [RFNoC: DmaFIFO] -> [QT GUI Frequency
Sink]
When I try to run it, I get the following error:
Traceback (most recent call last):
File "/home/user/src/rfnoc/examples/top_block.py", line 307, in <module>
main()
File "/home/user/src/rfnoc/examples/top_block.py", line 295, in main
tb = top_block_cls()
File "/home/user/src/rfnoc/examples/top_block.py", line 90, in __init__
0, -1
File "/usr/local/lib/python2.7/dist-packages/ettus/ettus_swig.py",
line 2706, in make
return _ettus_swig.rfnoc_radio_make(dev, tx_stream_args,
rx_stream_args, radio_select, device_select)
RuntimeError: basic_string::_M_construct null not valid
I have tried with Swig version 2.0.4 as well as 3.0.8 with the same
result. Also, I have switched DDC with DmaFIFO with no success.
UHD, gr-ettus and fpga are all newest versions from GitHub repos. Any
idea how I can fix this error?
Cheers,
Sebastian
------------------------------
Message: 5
Date: Wed, 1 Mar 2017 14:11:04 -0500
From: Jason Matusiak <[email protected]>
To: Sebastian Mueller <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] RuntimeError: basic_string::_M_construct
null not valid when using RFNoC:Radio
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Sebastian, do you have a Device3 block in your flowgraph (maybe post a
screenshot of your flowgraph)?
On 03/01/2017 12:14 PM, Sebastian Mueller via USRP-users wrote:
> Hi list,
>
> I'm currently trying to get a very basic RFNoC flowgraph running that
> looks like this:
>
> [RFNoC: Radio] -> [RFNoC: DDC] -> [RFNoC: DmaFIFO] -> [QT GUI Frequency
> Sink]
>
> When I try to run it, I get the following error:
>
> Traceback (most recent call last):
> File "/home/user/src/rfnoc/examples/top_block.py", line 307, in <module>
> main()
> File "/home/user/src/rfnoc/examples/top_block.py", line 295, in main
> tb = top_block_cls()
> File "/home/user/src/rfnoc/examples/top_block.py", line 90, in __init__
> 0, -1
> File "/usr/local/lib/python2.7/dist-packages/ettus/ettus_swig.py",
> line 2706, in make
> return _ettus_swig.rfnoc_radio_make(dev, tx_stream_args,
> rx_stream_args, radio_select, device_select)
> RuntimeError: basic_string::_M_construct null not valid
>
> I have tried with Swig version 2.0.4 as well as 3.0.8 with the same
> result. Also, I have switched DDC with DmaFIFO with no success.
> UHD, gr-ettus and fpga are all newest versions from GitHub repos. Any
> idea how I can fix this error?
>
> Cheers,
> Sebastian
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 6
Date: Wed, 1 Mar 2017 19:21:33 +0000
From: Stefano Bettelli <[email protected]>
To: Claudio Cicconetti <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates
Message-ID: <1C28F8990859A84D809CFC7AB0D38942A8543A@lhreml502-mbx>
Content-Type: text/plain; charset="iso-8859-1"
Dear Claudio,
I have found a noticeable improvement when fixing the buffer size to an integer
multiple of the "natural" buffer size.
Try replacing the samples-per-channel settings as follows:
const size_t natural_spp = tx_stream->get_max_num_samps();
const size_t min_spp = natural_spp*500;
const size_t max_spp = natural_spp*500;
(natural_spp is 496 I believe, so we are talking here of 248'000 samples, i.e.
992'000 bytes). With these settings I can TX on 2 channels at 100MS/s for tens
of seconds without errors. But 200MS/s still fails miserably.
I have also another finding. I have noticed that while in RX streams the UDP
packets have 8000 bytes payload, in TX the payload is reduced to something
around 2000. Also setting the send_frame_size to 8000 doesn't change this
behavior. I was wondering whether I had something wrong in my hardware
configuration, when I found the following very interesting lines in
host/lib/usrp/x300/x300_impl.hpp :
//static const size_t X300_PCIE_TX_DATA_FRAME_SIZE = 8192; // bytes
// This is a temporary solution: We're throttling PCIe MTU to avoid
// underruns on Tx. Once we solve it on the FPGA side, need revert this commit.
static const size_t X300_PCIE_TX_DATA_FRAME_SIZE = 3000; // bytes
[...]
// MTU throttling for Ethernet/TX (see above)
static const size_t X300_ETH_DATA_FRAME_MAX_TX_SIZE = 2000;
with 2000 bytes payload at 200MS/s one need to send a packet every 2.5us, which
is why the TX at this rate is failing so easily. With 8000 bytes it would be
10us, which is quite manageable. So, if anyone from Ettus is listening, is this
still an actual problem in the FPGA firmware or is it a forgotten commit?
Regards,
Stefano
-----Original Message-----
From: Claudio Cicconetti [mailto:[email protected]]
Sent: Mittwoch, 1. M?rz 2017 18:05
To: Stefano Bettelli <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates
Dear Stefano,
Fascinating issue.
I tried your example with a slightly different environment (X300, single
10 GbE connection to host, single WBX-120, uhd-3.10.1.1) but the result is the
*same*.
Basically the use case is:
- tx rate = 1 MS/s
- send size = 200 kS
* Scenario1
Sending a total of 1 MS (= 5 calls to send).
A burst ack is received after all sends have been done.
There are a lot of underflows.
* Scenario2
Same as above but sending a total of 2 MS (= 10 calls to send).
No burst ack is received, no underflows.
I tried disabled the time specification in the send() metadata, but the result
is the same. You can find the modified example at:
https://www.dropbox.com/s/m619yrox03cebuj/mybenchmark2.cpp?dl=0
By commenting / uncommenting lines 8 and 9 in the example you can switch
between Scenario1 and Scenario2.
Unfortunately, I could not spot any obvious flaws in your example.
Best regards,
Claudio
On 03/01/2017 01:41 PM, Stefano Bettelli wrote:
> Hi Claudio,
>
> -----Original Message-----
>> From: USRP-users [mailto:[email protected]] On
>> Behalf Of Claudio Cicconetti via USRP-users
>> Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates Hello
>> Stefano, Do you mind sharing the source code of your modified
>> benchmark_rate?
>
> In the spirit of the minimal working example I have prepared a simplified
> code that I attach at the end of this message.
> You have to recompile it to change parameters, because I have stripped out
> all option parsing, but it is a quick thing.
> In the main you can change the args string, the transmit rate, the # of
> channels and the init delay.
> In the send() subthread called b_tx_rate() you can change mainly how many
> samples per channel you send with each individual send().
> This benchmark runs till "target" (global variable) samples per channel have
> been sent, or till the send() returns 0.
>
> Compile it with the following command line:
> g++ -std=c++14 -Wall -Wextra -O3 -s -o mybenchmark mybenchmark.cpp
> g++ -luhd -lpthread -lboost_system
>
> I have an X310 with the XG firmware, and 2 10G cables, and I have tried it in
> the following configurations:
> 1) 2 ch, 1MS/s, 200'000 S/ch, target = 16'000'000 --> OK
> 2) like in 1) but target = 200'000 --> errors
> 3) like in 1) but the # of S/ch is randomly chosen between 200'000 and
> 200'500 --> errors
> 4) same as 1),2) and 3) with only one channel --> same results
>
> Analysing the traffic with Wireshark doesn't show any specific anomaly, nor
> large fluctuations in packet deltas (the transport tends to use UDP packet
> with about 2000B of payload, with a delta of 5-20 microseconds, while one
> packet needs 1ms to be processed by the USRP.
>
> I would be very interested to know whether you get the same results, and
> whether you spot any error in the program workflow.
> Thanks in advance,
> Stefano
>
> --------------- start of mybenchmark.cpp --------- cut here
> ------------------- #include <uhd/utils/thread_priority.hpp> #include
> <uhd/utils/safe_main.hpp> #include <uhd/usrp/multi_usrp.hpp> #include
> <iostream> #include <thread>
>
> std::vector<size_t> counts(256, 0); // async message counts size_t
> target { 16000000 }; // total # samples per channel to be TXed
>
> #include <chrono>
> #define NOW std::chrono::high_resolution_clock::now()
> #define DIF
> ((std::chrono::high_resolution_clock::now()-start).count()/1000)
>
> /*********************************************************************
> **
> * Attempt transmission with multiple send()'s
> **********************************************************************
> / void b_tx_rate(uhd::tx_streamer::sptr tx_stream,
> uhd::time_spec_t start_time, double tx_rate) {
> uhd::tx_metadata_t md;
> md.time_spec = start_time;
> md.has_time_spec = true;
> // const size_t natural_spp = tx_stream->get_max_num_samps();
> const size_t min_spp = 200000;//199600; // samples per channel
> const size_t max_spp = 200000; // samples per channel
> std::cout << "Using " << max_spp << " samples in send()" << std::endl;
> std::vector<char> buff(4 * max_spp); // sc16 is 4 bytes per sample
> const auto num_ch = tx_stream->get_num_channels();
> std::vector<const void *> pts(num_ch, &buff.front());
> auto start { NOW }; size_t accum { 0 };
> while (target > 0) {
> size_t act_spp = min_spp + (double(rand())/RAND_MAX)*(max_spp - min_spp);
> if (act_spp > target) act_spp = target;
> auto rel_time { md.time_spec }; rel_time -= start_time;
> std::cout << " spp " << act_spp << " alsent " << accum
> << " to send " << target << " time spec "
> << rel_time.get_real_secs() << std::endl;
> start = NOW;
> auto n = tx_stream->send(pts, act_spp, md);
> std::cout << "Send call time " << DIF << " sent= " << n << std::endl;
> accum += n; target -= n;
> start = NOW;
> md.time_spec += uhd::time_spec_t::from_ticks(n, tx_rate);
> md.has_time_spec = false;
> if (n == 0) { target = 0; break; /* stop on error */ } }
> md.has_time_spec = false;
> md.end_of_burst = true; // EOB packet
> tx_stream->send(pts, 0, md); }
>
> /*********************************************************************
> **
> * Handle asynchronous messages
>
> **********************************************************************
> / void b_tx_async(uhd::tx_streamer::sptr tx_stream) {
> uhd::async_metadata_t amd;
> size_t termination = 10; // delayed exit to catch late messages
> while (target > 0 || termination > 0) {
> if (not tx_stream->recv_async_msg(amd)) { // 100ms timeout
> if (target == 0) --termination; continue; }
> ++counts[amd.event_code]; } }
>
> /*********************************************************************
> **
> * Main code + dispatcher
>
> **********************************************************************
> / int UHD_SAFE_MAIN(int argc, char *argv[]){
> (void)argc; (void)argv;
> // ---------------------------------------------------------------
> std::string args { "addr=192.168.30.2,second_addr=192.168.40.2" };
> std::vector<size_t> tx_channels { 0,1 };
> double init_delay { 0.5 }; // 500mS
> double tx_rate { 1.0e6 };
> // ---------------------------------------------------------------
> uhd::set_thread_priority_safe();
> std::cout << "Creating the usrp device with: " << args << std::endl;
> auto usrp = uhd::usrp::multi_usrp::make(args);
> std::cout << "Using Device: " << usrp->get_pp_string() << std::endl;
> usrp->set_tx_rate(tx_rate);
> //usrp->set_tx_gain(20,0);
> usrp->set_time_unknown_pps(uhd::time_spec_t(0.0));
> uhd::stream_args_t stream_args("sc16", "sc16");
> stream_args.channels = tx_channels;
> auto tx_stream = usrp->get_tx_stream(stream_args);
> std::cout << "\nTX subdev_spec=" << usrp->get_tx_subdev_spec().to_string()
> << "\nTesting tx_rate=" << (usrp->get_tx_rate()/1.0e6) << "MS/s"
> << " chan=" << tx_stream->get_num_channels() << "\n\n";
> auto start_time = usrp->get_time_now() + uhd::time_spec_t(init_delay);
> std::thread tx { b_tx_rate , tx_stream, start_time, tx_rate };
> std::thread as { b_tx_async, tx_stream };
> tx.join(); as.join();
> #define CC(s) std::endl << #s": " << \
> counts[uhd::async_metadata_t::event_code_t::EVENT_CODE_ ## s]
> std::cout << CC(BURST_ACK) << CC(UNDERFLOW) << CC(SEQ_ERROR)
> << CC(TIME_ERROR) << CC(UNDERFLOW_IN_PACKET)
> << CC(SEQ_ERROR_IN_BURST) << CC(USER_PAYLOAD) << std::endl;
> return EXIT_SUCCESS; }
>
------------------------------
Message: 7
Date: Wed, 1 Mar 2017 11:24:24 -0800
From: Michael West <[email protected]>
To: Roman Olesyuk <[email protected]>
Cc: Nikita Airee <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] No GPSDO found message
Message-ID:
<cam4xkrrhoafhzrzcsj3_cgr8hmxapefxg3uvdbgcy7490fv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
When using PCIe, the FPGA image is reloaded. That causes a reset of the
GPSDO. The changes in the commit attempted to wait long enough for the
GPSDO firmware to initialize, but not so long as to slow down device
initialization if no GPSDO was present. You can try increasing the timeout
on this line to see if it fixes the issue:
https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/gps_ctrl.cpp#L210
Regards,
Michael
On Tue, Feb 28, 2017 at 1:57 AM, Roman Olesyuk <[email protected]>
wrote:
> Hi Michael,
>
> I use the latest UHD and FPGA image 3.10.1.1 and still experiece this
> issue. My OS is Ubuntu 16.04.2, kernel 4.4.0-64-generic #85 x86_64, NI RIO
> drivers 15.0.0. In addition I have unstable PPS/GPS LOCK behavior as
> desribed in my previous email (e.g. stable PPS/GPS LOCK only when PC with
> PCIe card is power off).
>
> --
> ? ?????????, ????? ??????.
> Yours sincerely, Roman Olesyuk.
>
>
> 28 ????. 2017 ?. 10:33 ???????????? "Nikita Airee" <[email protected]>
> ???????:
>
> No Roman, I don't see such a behaviour in my USRP. Because in my case the
> GPS refuses to lock but the PPS works fine blinking every second. Did you
> try the patch? Does it work for you?
>
> Michael, thanks for your suggestion! But it seems like it is not working
> for me. It is entirely possible that I may be doing something wrong because
> I have never patched a commit before. But the gps_ctrl.cpp file does change
> at its location <working directory>/uhd/host/usrp/.
>
> Also for when the gpsdo does work, ie with Ethernet, how do I get this
> gpsdo to lock? I suppose simply running sync_to_gps should time and
> reference lock my gpsdo?
>
> Bests,
> Nikita
>
>
> On Tue, Feb 28, 2017 at 4:06 AM, Michael West <[email protected]>
> wrote:
>
>> Hi Nikita,
>>
>> Sadly, we know what this issue is. We sped up the X300 initialization so
>> much that the firmware on the GPSDO does not have time to finish
>> initializing before the detection code runs. The problem was fixed in the
>> 3.10.1.1 release, but for some reason the fix did not get applied to the
>> 3.9.6 release. The specific commit that is needed is
>> https://github.com/EttusResearch/uhd/commit/63fcfb9574d64797
>> b807a0dd356f5d7bfc48f082
>>
>> You can try to patch with that commit until we get it properly fixed. We
>> should have it fixed on the LTS branch soon.
>>
>> Regards,
>> Michael
>>
>> On Mon, Feb 27, 2017 at 12:27 PM, Roman Olesyuk via USRP-users <
>> [email protected]> wrote:
>>
>>> Hi Nikita,
>>>
>>> I experience the same issue. In addition I observe the following
>>> behavior. I checked LEDs on GPSDO board. Two green LEDs are on for
>>> several seconds when I power on X310 and then they go off. If the PCIe
>>> connector is plugged in, but PC is powered off, in about 30-60 seconds I
>>> observe that PPS LED starts blinking once per seconds, and after about 10
>>> minutes GPS LOCK LED (on GPSDO boards and on the front panel) goes on. This
>>> is very stable behavior when PCIe IS PLUGGED IN, BUT PC IS OFF. I can get
>>> very stable GPS lock (the LED is on as long as I can observe) and PPS is
>>> always blinking. If I use 1Gbps network connection (with PCIe connector
>>> unplugged) or if I use PCIe connection (just power on X310, then power on
>>> PC), I do not see PPS blinking even after several minutes. Sometimes PPS
>>> LED goes blinking and after 10-60 seconds it goes off again. Very rarely I
>>> can see PPS blinking for several minutes and GPS LOCK LED is even rarer
>>> (almost never see it). The behaviors are almost the same in PCIe and 1Gbps
>>> modes. So it looks for me like some FPGA/GPSDO initialization problem.
>>>
>>> Can you confirm my observations?
>>>
>>> --
>>> Yours sincerely, Roman Olesyuk.
>>>
>>> 2017-02-27 13:43 GMT+03:00 Nikita Airee via USRP-users <
>>> [email protected]>:
>>>
>>>> Hi list,
>>>>
>>>> the information I had provided might not have been enough. So here is
>>>> some more:
>>>>
>>>> My X310 has internal GPSDO. This is visible to UHD when I perform
>>>> uhd_usrp_probe provided it is connected to my laptop using Gigabit
>>>> ethernet:
>>>>
>>>> linux; GNU C++ version 4.8.4; Boost_106000; UHD_003.009.006-0-g122d5f8e
>>>>
>>>> -- X300 initialization sequence...
>>>> -- Determining maximum frame size... 1472 bytes.
>>>> -- Setup basic communication...
>>>> -- Loading values from EEPROM...
>>>> -- Setup RF frontend clocking...
>>>> -- Radio 1x clock:200
>>>> -- *Detecting internal GPSDO.... Found an internal GPSDO: LC_XO,
>>>> Firmware Rev 0.929a*
>>>> -- Initialize Radio0 control...
>>>> -- Performing register loopback test... pass
>>>> -- Initialize Radio1 control...
>>>> -- Performing register loopback test... pass
>>>> ...
>>>>
>>>> However, when I use PCI Express for connection, it says:
>>>>
>>>> linux; GNU C++ version 4.8.4; Boost_106000; UHD_003.009.006-0-g122d5f8e
>>>>
>>>> -- X300 initialization sequence...
>>>> -- Connecting to niusrpriorpc at localhost:5444...
>>>> -- Using LVBITX bitfile /usr/local/share/uhd/images/us
>>>> rp_x310_fpga_HGS.lvbitx...
>>>> -- Setup basic communication...
>>>> -- Loading values from EEPROM...
>>>> -- Setup RF frontend clocking...
>>>> -- Radio 1x clock:200
>>>> --
>>>>
>>>>
>>>> *Detecting internal GPSDO.... UHD Error: GPS invalid reply "",
>>>> assuming none availableNo GPSDO found*
>>>> -- Initialize Radio0 control...
>>>> -- Performing register loopback test... pass
>>>> -- Initialize Radio1 control...
>>>> -- Performing register loopback test... pass
>>>> ...
>>>>
>>>> When the same USRP is connected to a laptop with a different UHD
>>>> version via PCIe, I get:
>>>>
>>>> linux; GNU C++ version 4.8.2; Boost_106000; UHD_3.11.0.git-28-gc66cb1ba
>>>>
>>>> -- X300 initialization sequence...
>>>> -- Connecting to niusrpriorpc at localhost:5444...
>>>> -- Using LVBITX bitfile /usr/local/share/uhd/images/us
>>>> rp_x310_fpga_HG.lvbitx...
>>>> -- Setup basic communication...
>>>> -- Loading values from EEPROM...
>>>> -- Setup RF frontend clocking...
>>>> -- Radio 1x clock:200
>>>> -- *Detecting internal GPSDO.... Found an internal GPSDO: LC_XO,
>>>> Firmware Rev 0.929a*
>>>> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1186.1MB/s)
>>>> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1189.4MB/s)
>>>> -- [RFNoC Radio] Performing register loopback test... pass
>>>> -- [RFNoC Radio] Performing register loopback test... pass
>>>> -- [RFNoC Radio] Performing register loopback test... pass
>>>> -- [RFNoC Radio] Performing register loopback test... pass
>>>> -- Performing timer loopback test... pass
>>>> -- Performing timer loopback test... pass
>>>> ...
>>>>
>>>> Also when I try sync_to_gps, it says:
>>>> ...
>>>> Waiting for reference lock...LOCKED
>>>> *WARNING: GPS not locked - time will not be accurate until locked *
>>>> USRP time: 1136078288.000000000
>>>> GPSDO time: 1136078288.000000000
>>>>
>>>> SUCCESS: USRP time synchronized to GPS time
>>>>
>>>> On querying gpsdo sensors soon after, I find that :
>>>>
>>>> USRP Locked to GPSDO 10 MHz Reference.
>>>>
>>>> GPS and UHD Device time are NOT aligned;
>>>> last_pps: 9 vs gps: 1136078227. Trying to set the device time to GPS
>>>> time...
>>>> -- 1) catch time transition at pps edge
>>>> -- 2) set times next pps (synchronously)
>>>> last_pps: 1136078231 vs gps: 1136078231.
>>>> GPS and UHD Device time are aligned.
>>>> Printing available NMEA strings:
>>>> GPS_GPGGA:
>>>> $GPGGA,011711.00,0000.0000,N,00000.0000,E,0,99,1.0,0.0,M,0.0,M,,*5B
>>>>
>>>> GPS_GPRMC: $GPRMC,011711.00,V,0000.0000,N,00000.0000,E,0.0,0.0,010106,,*25
>>>>
>>>> GPS Epoch time at last PPS: 1136078232.00000 seconds
>>>> UHD Device time last PPS: 1136078232.00000 seconds
>>>> UHD Device time right now: 1136078232.27291 seconds
>>>> PC Clock time: 1487756260 seconds
>>>> ...
>>>>
>>>> Could anybody please help me with this? I suppose that when the gps is
>>>> locked, it means that uhd is time aligned with gps? If so, I would also
>>>> really like to know exactly how you permanently lock gps.
>>>>
>>>> Bests,
>>>> Nikita Airee
>>>>
>>>>
>>>> On Tue, Feb 21, 2017 at 8:20 PM, Nikita Airee <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi list,
>>>>>
>>>>> I have:
>>>>>
>>>>> Ubuntu 14.04
>>>>>
>>>>> UHD: 003.009.006-0-g122d5f8e
>>>>>
>>>>> USRP X310 with CBX20 + GPSDO
>>>>>
>>>>> I moved to UHD 3.9.6 very recently and since then have been facing the
>>>>> following issue related to GPSDO:
>>>>>
>>>>> *UHD Error: GPS invalid reply "", assuming none available
>>>>> No GPSDO found*
>>>>>
>>>>> UHD_3.11.0.git-28-gc66cb1ba would never throw up this message.
>>>>>
>>>>> Is this a known issue? If not, how do I use GPSDO?
>>>>>
>>>>> Bests,
>>>>>
>>>>> Nikita Airee
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>
>>>
>>> --
>>> ? ?????????, ????? ??????.
>>> Yours sincerely, Roman Olesyuk.
>>>
>>> _______________________________________________
>>> 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/20170301/1e2f9a88/attachment-0001.html>
------------------------------
Message: 8
Date: Wed, 1 Mar 2017 15:06:52 -0500
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] B205mini power usage
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Are there any documentation listed anywhere on the mini's power draw?
I am attempting to get it to enumerate on a phone and the power light
comes on, but Android on some (not all) phones doesn't enumerate it. It
makes me wonder if maybe it is trying to draw too much power for the
phone to handle comfortably. I am using the full USB3 connector to a
USB-OTG C adapter to the phone.
------------------------------
Message: 9
Date: Wed, 01 Mar 2017 15:27:31 -0500
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B205mini power usage
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 03/01/2017 03:06 PM, Jason Matusiak via USRP-users wrote:
> Are there any documentation listed anywhere on the mini's power draw?
>
> I am attempting to get it to enumerate on a phone and the power light
> comes on, but Android on some (not all) phones doesn't enumerate it.
> It makes me wonder if maybe it is trying to draw too much power for
> the phone to handle comfortably. I am using the full USB3 connector
> to a USB-OTG C adapter to the phone.
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
There's a power-consumption table for B210 here which can give you a
rough idea:
https://kb.ettus.com/B200/B210/B200mini/B205mini
But if it's not enumerating, the sounds like a controller issue.
------------------------------
Message: 10
Date: Wed, 1 Mar 2017 13:17:24 -0800
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] R: header file msg.hpp in the uhd release
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Daniele,
msg.hpp (and the msg namespace) was removed on master branch. See my
recent post with the subject line "Logging Infrastructure changes on
master branch".
-- M
On 02/28/2017 07:24 AM, Disco Daniele via USRP-users wrote:
> I?ve forgotten to say that msg.hpp is not present in the ?master? version
>
>
>
>
>
> *Da:*Disco Daniele
> *Inviato:* marted? 28 febbraio 2017 15:54
> *A:* [email protected]
> *Cc:* Daniele Disco
> *Oggetto:* header file msg.hpp in the uhd release
>
>
>
> Hi!
>
> Few days ago I download from github the last release of uhd.
>
> Having problems with a sw, I discovered that in the include files
> (/usr/local/include/uhd/utils) the header file msg.hpp is not present.
>
> It is normal?
>
> Now where is declared the namespace msg?
>
> Thank You
>
> Best Regards
>
> Daniele
>
>
>
> _____________________________________________**
>
> logo1*
> **Daniele Disco*
> Engeenering & Tilab ? Wireless Access
> Wireless Innovation
> Via Reiss Romoli, 274 ? 10148 Torino
> tel . +39 011 228 7271
> cell. +39 331 600 1113
>
> Fax. +39 06 4186 5196
> Tim Official: *Facebook* <https://www.facebook.com/TimOfficialPage> -
> *Twitter* <https://twitter.com/tim_official>
> *www.tim.it* <http://www.tim.it/>
>
>
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione
> derivante dalla conoscenza di queste informazioni sono rigorosamente
> vietate. Qualora abbiate ricevuto questo documento per errore siete
> cortesemente pregati di darne immediata comunicazione al mittente e di
> provvedere alla sua distruzione, Grazie.
>
> /This e-mail and any attachments// is //confidential and may contain
> privileged information intended for the addressee(s) only.
> Dissemination, copying, printing or use by anybody else is unauthorised.
> If you are not the intended recipient, please delete this message and
> any attachments and advise the sender by return e-mail, Thanks./
>
> *rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non
> ? necessario.*
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 11
Date: Wed, 1 Mar 2017 21:34:47 +0000
From: "[email protected]" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Increase number of tx burst send timed commands
in UHD
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hello,
Does anyone know how to increase the buffer size for the number of sends
that I can load in the future with successive calls to the send function in
UHD?
I am using an X310 over 10 Gigabit Ethernet with UHD 3.11. I want to be able
to get very reliable TX sends at specific times in the future but
occasionally the Linux OS gets held up and delays the delivery of the send
to the X310. So if you buffer numerous send commands, any hang-ups in the OS
can be alleviated and bursts will be sent at the correct time.
Anyone have this buffering experience or suggestions?
Jacob Cooper
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170301/8221cbb2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5118 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170301/8221cbb2/attachment-0001.p7s>
------------------------------
Message: 12
Date: Wed, 1 Mar 2017 23:15:41 +0000
From: Disco Daniele <[email protected]>
To: "[email protected]" <[email protected]>
Cc: Disco Daniele <[email protected]>
Subject: [USRP-users] Install uhd on Raspberry Pi 3
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi!
In these days I'm trying to install the uhd library on Raspberry Pi 3 Model B.
Starting from
https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux<https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_%28UHD_and_GNU_Radio%29_on_Linux>,
I used like image for the Pi ubuntu mate.
Is a porting of ubuntu for the Pi with version 16.04.
I erased all the applications non necessary, upgraded the distribution and
installed all the application reported for 16.04 (fyi some packages are
reported twice like doxygen).
Than I used the uhd-master version (using the download from uhd github site)
and at the end I installed uhd.
Running the tests no error was reported.
Than I compiled another sw that use the namespace uhd::msg and it failed
because the namespace in the master is not present (if you look in
/usr/local/include/uhd/utils/msg.hpp is not present).
Looking in the repository I verified that in the master distribution this
header file is not present but in the other releases (like the last one) this
header is present.
So using the procedure
git clone https://github.com/EttusResearch/uhd
cd uhd
git checkout release_00X_00y_00z
I download the last release of uhd. I ported this directory on raspberry pi and
the compilation goes on
just to build the uhd.so library.
Then compiling the first of test example the code crash for errors.
Please, could you help me to solve this strange case?
Thank you
Daniele
PS: If I'm interested only on uhd but not in gnuradio, it is possible to
separate in the page
https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux<https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_%28UHD_and_GNU_Radio%29_on_Linux>,
the apps/libs necessary for uhd respect to the apps/libs necessary to gnuradio.
Thank you again
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone
indicate. La diffusione, copia o qualsiasi altra azione derivante dalla
conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate
ricevuto questo documento per errore siete cortesemente pregati di darne
immediata comunicazione al mittente e di provvedere alla sua distruzione,
Grazie.
This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intended
recipient, please delete this message and any attachments and advise the sender
by return e-mail, Thanks.
[rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non ?
necessario.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170301/5ff9b61f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo Ambiente_foglia2.jpg
Type: image/jpeg
Size: 677 bytes
Desc: logo Ambiente_foglia2.jpg
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170301/5ff9b61f/attachment-0001.jpg>
------------------------------
Message: 13
Date: Wed, 1 Mar 2017 23:22:01 +0000
From: Disco Daniele <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] sorry to duplicate post
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Thank you for your answer.
Sorry for the new post related to Raspberry PI.
I didn't see your answer related to the namespace msg.
Daniele
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone
indicate. La diffusione, copia o qualsiasi altra azione derivante dalla
conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate
ricevuto questo documento per errore siete cortesemente pregati di darne
immediata comunicazione al mittente e di provvedere alla sua distruzione,
Grazie.
This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intended
recipient, please delete this message and any attachments and advise the sender
by return e-mail, Thanks.
[rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non ?
necessario.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170301/404ec7ec/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo Ambiente_foglia2.jpg
Type: image/jpeg
Size: 677 bytes
Desc: logo Ambiente_foglia2.jpg
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170301/404ec7ec/attachment-0001.jpg>
------------------------------
Message: 14
Date: Wed, 1 Mar 2017 16:35:46 -0800
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Install uhd on Raspberry Pi 3
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
uhd::msg was removed on master branch recently (see my post with subject
"Logging Infrastructure changes on master branch"). What's the software
you're compiling?
-- M
On 03/01/2017 03:15 PM, Disco Daniele via USRP-users wrote:
> Hi!
>
> In these days I'm trying to install the uhd library on Raspberry Pi 3
> Model B.
>
> Starting from
>
> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux
> <https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_%28UHD_and_GNU_Radio%29_on_Linux>,
> I used like image for
> the Pi ubuntu mate.
>
> Is a porting of ubuntu for the Pi with version 16.04.
>
> I erased all the applications non
> necessary, upgraded the distribution and installed all
> the application reported for 16.04 (fyi some packages are reported twice
> like doxygen).
>
> Than I used the uhd-master version (using the download from uhd
> github site) and at the end I installed uhd.
>
> Running the tests no error was reported.
>
> Than I compiled another sw that use the namespace uhd::msg and it failed
> because the namespace in the master is not present (if you look in
> /usr/local/include/uhd/utils/msg.hpp is not present).
>
>
> Looking in the repository I verified that in the
> master distribution this header file is
> not present but in the other releases (like the last
> one) this header is present.
>
>
> So using the procedure
>
> git clone https://github.com/EttusResearch/uhd
> cd uhd
>
> git checkout release_00X_00y_00z
>
> I download the last release of uhd. I ported this directory on raspberry
> pi and the compilation goes on
> just to build the uhd.so library.
>
> Then compiling the first of test example the code crash for errors.
>
> Please, could you help me to solve this strange case?
> Thank you
> Daniele
> PS: If I'm interested only on uhd but not in gnuradio, it is possible to
> separate in the page
> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux
> <https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_%28UHD_and_GNU_Radio%29_on_Linux>,
>
> the apps/libs necessary for uhd respect to the apps/libs necessary to
> gnuradio.
> Thank you again
>
>
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione
> derivante dalla conoscenza di queste informazioni sono rigorosamente
> vietate. Qualora abbiate ricevuto questo documento per errore siete
> cortesemente pregati di darne immediata comunicazione al mittente e di
> provvedere alla sua distruzione, Grazie.
>
> /This e-mail and any attachments// is //confidential and may contain
> privileged information intended for the addressee(s) only.
> Dissemination, copying, printing or use by anybody else is unauthorised.
> If you are not the intended recipient, please delete this message and
> any attachments and advise the sender by return e-mail, Thanks./
>
> *rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non
> ? necessario.*
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 15
Date: Wed, 1 Mar 2017 19:52:21 -0500
From: Rohit Dilip <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP B200
Message-ID:
<CALumccfdMcTuvuuqxo5A0OUamOzGp_KW6q776xz4KY=fpte...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey all,
I apologize in advance if this isn't how this listserv is meant to be used
-- if I'm breaking some sort of protocol, I'd really appreciate if someone
could help me out.
I recently purchased a USRP B200, and I'd appreciate any advice on how to
reprogram the FPGA. I want to implement direct digital synthesis with the
FPGA so I can use the board to generate a waveform composed of a
superposition of 128 frequencies and amplitudes. I haven't really used this
board for FPGA programming, and haven't had much luck with Ettus's online
guide. Any advice on where to get started?
Best,
Rohit
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170301/76b52358/attachment-0001.html>
------------------------------
Message: 16
Date: Wed, 1 Mar 2017 17:06:10 -0800
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP B200
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Rohit,
this is the right place to ask this question. However, this sounds like
something that could easily be done through software -- any specific
reason you want to do this via GNU Radio, for example?
-- M
On 03/01/2017 04:52 PM, Rohit Dilip via USRP-users wrote:
> Hey all,
>
> I apologize in advance if this isn't how this listserv is meant to be
> used -- if I'm breaking some sort of protocol, I'd really appreciate if
> someone could help me out.
>
> I recently purchased a USRP B200, and I'd appreciate any advice on how
> to reprogram the FPGA. I want to implement direct digital synthesis with
> the FPGA so I can use the board to generate a waveform composed of a
> superposition of 128 frequencies and amplitudes. I haven't really used
> this board for FPGA programming, and haven't had much luck with Ettus's
> online guide. Any advice on where to get started?
>
> Best,
> Rohit
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 17
Date: Wed, 1 Mar 2017 17:10:35 -0800
From: Martin Braun <[email protected]>
To: Rohit Dilip <[email protected]>,
"'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] USRP B200
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Rohit,
please keep this thread on the mailing list.
You can't reprogram the FPGA from GNU Radio, that's quite an involved
process. But generating a signal and then sending it from GNU Radio
seems like it would do the same thing.
-- M
On 03/01/2017 05:09 PM, Rohit Dilip wrote:
> I actually wasn't thinking specifically about using GNUradio, I thought
> I'd have to implement FPGA programming using Verilog of VHDL. I think
> the issue with GNURadio would be I would be storing the waveforms in a
> buffer and then sending to the device, which could lead to some phase
> decoherence? Or is there a way to program the FPGA from GNUradio?
>
> On Wed, Mar 1, 2017 at 8:06 PM, Martin Braun via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Rohit,
>
> this is the right place to ask this question. However, this sounds like
> something that could easily be done through software -- any specific
> reason you want to do this via GNU Radio, for example?
>
> -- M
>
> On 03/01/2017 04:52 PM, Rohit Dilip via USRP-users wrote:
> > Hey all,
> >
> > I apologize in advance if this isn't how this listserv is meant to be
> > used -- if I'm breaking some sort of protocol, I'd really
> appreciate if
> > someone could help me out.
> >
> > I recently purchased a USRP B200, and I'd appreciate any advice on how
> > to reprogram the FPGA. I want to implement direct digital
> synthesis with
> > the FPGA so I can use the board to generate a waveform composed of a
> > superposition of 128 frequencies and amplitudes. I haven't really used
> > this board for FPGA programming, and haven't had much luck with
> Ettus's
> > online guide. Any advice on where to get started?
> >
> > Best,
> > Rohit
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected] <mailto:[email protected]>
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
> >
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>
>
>
>
> --
> -Rohit Dilip
------------------------------
Message: 18
Date: Wed, 1 Mar 2017 20:11:56 -0500
From: Rohit Dilip <[email protected]>
To: Martin Braun <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP B200
Message-ID:
<CALumcce=r2+wdd4p+fpxb0vz91cqfe+eqcdnj6yatlxjhha...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Wouldn't the PC have to keep sending fresh data, which would prevent long
term phase coherence?
On Wed, Mar 1, 2017 at 8:10 PM, Martin Braun <[email protected]> wrote:
> Rohit,
>
> please keep this thread on the mailing list.
> You can't reprogram the FPGA from GNU Radio, that's quite an involved
> process. But generating a signal and then sending it from GNU Radio
> seems like it would do the same thing.
>
> -- M
>
> On 03/01/2017 05:09 PM, Rohit Dilip wrote:
> > I actually wasn't thinking specifically about using GNUradio, I thought
> > I'd have to implement FPGA programming using Verilog of VHDL. I think
> > the issue with GNURadio would be I would be storing the waveforms in a
> > buffer and then sending to the device, which could lead to some phase
> > decoherence? Or is there a way to program the FPGA from GNUradio?
> >
> > On Wed, Mar 1, 2017 at 8:06 PM, Martin Braun via USRP-users
> > <[email protected] <mailto:[email protected]>> wrote:
> >
> > Rohit,
> >
> > this is the right place to ask this question. However, this sounds
> like
> > something that could easily be done through software -- any specific
> > reason you want to do this via GNU Radio, for example?
> >
> > -- M
> >
> > On 03/01/2017 04:52 PM, Rohit Dilip via USRP-users wrote:
> > > Hey all,
> > >
> > > I apologize in advance if this isn't how this listserv is meant to
> be
> > > used -- if I'm breaking some sort of protocol, I'd really
> > appreciate if
> > > someone could help me out.
> > >
> > > I recently purchased a USRP B200, and I'd appreciate any advice on
> how
> > > to reprogram the FPGA. I want to implement direct digital
> > synthesis with
> > > the FPGA so I can use the board to generate a waveform composed of
> a
> > > superposition of 128 frequencies and amplitudes. I haven't really
> used
> > > this board for FPGA programming, and haven't had much luck with
> > Ettus's
> > > online guide. Any advice on where to get started?
> > >
> > > Best,
> > > Rohit
> > >
> > >
> > > _______________________________________________
> > > USRP-users mailing list
> > > [email protected] <mailto:[email protected]>
> > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> > <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
> > >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected] <mailto:[email protected]>
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> > <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
> >
> >
> >
> >
> > --
> > -Rohit Dilip
>
>
--
-Rohit Dilip
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170301/ea8384c3/attachment-0001.html>
------------------------------
Message: 19
Date: Wed, 1 Mar 2017 17:15:16 -0800
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] USRP B200
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On 03/01/2017 05:11 PM, Rohit Dilip wrote:
> Wouldn't the PC have to keep sending fresh data, which would prevent
> long term phase coherence?
Yes, and no. The two streams have locked sample clocks, and share an LO.
-- M
>
> On Wed, Mar 1, 2017 at 8:10 PM, Martin Braun <[email protected]
> <mailto:[email protected]>> wrote:
>
> Rohit,
>
> please keep this thread on the mailing list.
> You can't reprogram the FPGA from GNU Radio, that's quite an involved
> process. But generating a signal and then sending it from GNU Radio
> seems like it would do the same thing.
>
> -- M
>
> On 03/01/2017 05:09 PM, Rohit Dilip wrote:
> > I actually wasn't thinking specifically about using GNUradio, I thought
> > I'd have to implement FPGA programming using Verilog of VHDL. I think
> > the issue with GNURadio would be I would be storing the waveforms in a
> > buffer and then sending to the device, which could lead to some phase
> > decoherence? Or is there a way to program the FPGA from GNUradio?
> >
> > On Wed, Mar 1, 2017 at 8:06 PM, Martin Braun via USRP-users
> > <[email protected] <mailto:[email protected]>
> <mailto:[email protected]
> <mailto:[email protected]>>> wrote:
> >
> > Rohit,
> >
> > this is the right place to ask this question. However, this
> sounds like
> > something that could easily be done through software -- any
> specific
> > reason you want to do this via GNU Radio, for example?
> >
> > -- M
> >
> > On 03/01/2017 04:52 PM, Rohit Dilip via USRP-users wrote:
> > > Hey all,
> > >
> > > I apologize in advance if this isn't how this listserv is
> meant to be
> > > used -- if I'm breaking some sort of protocol, I'd really
> > appreciate if
> > > someone could help me out.
> > >
> > > I recently purchased a USRP B200, and I'd appreciate any
> advice on how
> > > to reprogram the FPGA. I want to implement direct digital
> > synthesis with
> > > the FPGA so I can use the board to generate a waveform
> composed of a
> > > superposition of 128 frequencies and amplitudes. I haven't
> really used
> > > this board for FPGA programming, and haven't had much luck with
> > Ettus's
> > > online guide. Any advice on where to get started?
> > >
> > > Best,
> > > Rohit
> > >
> > >
> > > _______________________________________________
> > > USRP-users mailing list
> > > [email protected]
> <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > >
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
> > <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>>
> > >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> >
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
> >
> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>>
> >
> >
> >
> >
> > --
> > -Rohit Dilip
>
>
>
>
> --
> -Rohit Dilip
------------------------------
Message: 20
Date: Wed, 1 Mar 2017 20:25:35 -0500
From: Rohit Dilip <[email protected]>
To: Martin Braun <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP B200
Message-ID:
<calumccebmkgxbeabgmusrupuy7tobdkcapqsewnkkrn7mgg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
A couple of further questions, firstly, how is the frequency resolution in
using the GNURadio solution compared to DDS? Do you have any advice on if I
wanted to directly reprogram the FPGA and use DDS?
Really appreciate all the help!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170301/0906943c/attachment-0001.html>
------------------------------
Message: 21
Date: Wed, 1 Mar 2017 17:25:51 -0800
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Guys,
I can barely keep up. Hopefully this answers some of the questions:
- send()-ing an integer multiple of the packet size is the most
performant. Internally, it's not a big difference if you call send()
with N times the packet size, or 1 times the packet size. However, if
you don't have an integer multiple, some packets will be smaller than
the maximum packet size, thus bringing down performance.
- The *thread* that calls send() indeed shouldn't also be doing lots of
other stuff. GNU Radio does this, for example. We have producer/consumer
threads.
- The MTU throttling value of 2000 bytes is something we might be able
to take out, but we're not quite convinced yet. It depends on the exact
buffer sizes we have on the FPGA. Please note, we are currently actively
optimizing the Tx performance. We have a bunch of changes in the
pipeline, and bringing this value back up is one of them. For 200 Msps,
an MTU of 2000 is definitely problematic, so eventually it will need to
go up again.
Cheers,
Martin
On 03/01/2017 11:21 AM, Stefano Bettelli via USRP-users wrote:
> Dear Claudio,
>
> I have found a noticeable improvement when fixing the buffer size to an
> integer multiple of the "natural" buffer size.
> Try replacing the samples-per-channel settings as follows:
>
> const size_t natural_spp = tx_stream->get_max_num_samps();
> const size_t min_spp = natural_spp*500;
> const size_t max_spp = natural_spp*500;
>
> (natural_spp is 496 I believe, so we are talking here of 248'000 samples,
> i.e. 992'000 bytes). With these settings I can TX on 2 channels at 100MS/s
> for tens of seconds without errors. But 200MS/s still fails miserably.
>
> I have also another finding. I have noticed that while in RX streams the UDP
> packets have 8000 bytes payload, in TX the payload is reduced to something
> around 2000. Also setting the send_frame_size to 8000 doesn't change this
> behavior. I was wondering whether I had something wrong in my hardware
> configuration, when I found the following very interesting lines in
> host/lib/usrp/x300/x300_impl.hpp :
>
> //static const size_t X300_PCIE_TX_DATA_FRAME_SIZE = 8192; // bytes
> // This is a temporary solution: We're throttling PCIe MTU to avoid
> // underruns on Tx. Once we solve it on the FPGA side, need revert this
> commit.
> static const size_t X300_PCIE_TX_DATA_FRAME_SIZE = 3000; // bytes
> [...]
> // MTU throttling for Ethernet/TX (see above)
> static const size_t X300_ETH_DATA_FRAME_MAX_TX_SIZE = 2000;
>
> with 2000 bytes payload at 200MS/s one need to send a packet every 2.5us,
> which is why the TX at this rate is failing so easily. With 8000 bytes it
> would be 10us, which is quite manageable. So, if anyone from Ettus is
> listening, is this still an actual problem in the FPGA firmware or is it a
> forgotten commit?
>
> Regards,
> Stefano
>
> -----Original Message-----
> From: Claudio Cicconetti [mailto:[email protected]]
> Sent: Mittwoch, 1. M?rz 2017 18:05
> To: Stefano Bettelli <[email protected]>
> Cc: [email protected]
> Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates
>
> Dear Stefano,
> Fascinating issue.
>
> I tried your example with a slightly different environment (X300, single
> 10 GbE connection to host, single WBX-120, uhd-3.10.1.1) but the result is
> the *same*.
>
> Basically the use case is:
> - tx rate = 1 MS/s
> - send size = 200 kS
>
> * Scenario1
>
> Sending a total of 1 MS (= 5 calls to send).
> A burst ack is received after all sends have been done.
> There are a lot of underflows.
>
> * Scenario2
>
> Same as above but sending a total of 2 MS (= 10 calls to send).
> No burst ack is received, no underflows.
>
> I tried disabled the time specification in the send() metadata, but the
> result is the same. You can find the modified example at:
>
> https://www.dropbox.com/s/m619yrox03cebuj/mybenchmark2.cpp?dl=0
>
> By commenting / uncommenting lines 8 and 9 in the example you can switch
> between Scenario1 and Scenario2.
>
> Unfortunately, I could not spot any obvious flaws in your example.
>
> Best regards,
> Claudio
>
> On 03/01/2017 01:41 PM, Stefano Bettelli wrote:
>> Hi Claudio,
>>
>> -----Original Message-----
>>> From: USRP-users [mailto:[email protected]] On
>>> Behalf Of Claudio Cicconetti via USRP-users
>>> Subject: Re: [USRP-users] Asymmetry in achievable TX/RX rates Hello
>>> Stefano, Do you mind sharing the source code of your modified
>>> benchmark_rate?
>>
>> In the spirit of the minimal working example I have prepared a simplified
>> code that I attach at the end of this message.
>> You have to recompile it to change parameters, because I have stripped out
>> all option parsing, but it is a quick thing.
>> In the main you can change the args string, the transmit rate, the # of
>> channels and the init delay.
>> In the send() subthread called b_tx_rate() you can change mainly how many
>> samples per channel you send with each individual send().
>> This benchmark runs till "target" (global variable) samples per channel have
>> been sent, or till the send() returns 0.
>>
>> Compile it with the following command line:
>> g++ -std=c++14 -Wall -Wextra -O3 -s -o mybenchmark mybenchmark.cpp
>> g++ -luhd -lpthread -lboost_system
>>
>> I have an X310 with the XG firmware, and 2 10G cables, and I have tried it
>> in the following configurations:
>> 1) 2 ch, 1MS/s, 200'000 S/ch, target = 16'000'000 --> OK
>> 2) like in 1) but target = 200'000 --> errors
>> 3) like in 1) but the # of S/ch is randomly chosen between 200'000 and
>> 200'500 --> errors
>> 4) same as 1),2) and 3) with only one channel --> same results
>>
>> Analysing the traffic with Wireshark doesn't show any specific anomaly, nor
>> large fluctuations in packet deltas (the transport tends to use UDP packet
>> with about 2000B of payload, with a delta of 5-20 microseconds, while one
>> packet needs 1ms to be processed by the USRP.
>>
>> I would be very interested to know whether you get the same results, and
>> whether you spot any error in the program workflow.
>> Thanks in advance,
>> Stefano
>>
>> --------------- start of mybenchmark.cpp --------- cut here
>> ------------------- #include <uhd/utils/thread_priority.hpp> #include
>> <uhd/utils/safe_main.hpp> #include <uhd/usrp/multi_usrp.hpp> #include
>> <iostream> #include <thread>
>>
>> std::vector<size_t> counts(256, 0); // async message counts size_t
>> target { 16000000 }; // total # samples per channel to be TXed
>>
>> #include <chrono>
>> #define NOW std::chrono::high_resolution_clock::now()
>> #define DIF
>> ((std::chrono::high_resolution_clock::now()-start).count()/1000)
>>
>> /*********************************************************************
>> **
>> * Attempt transmission with multiple send()'s
>> **********************************************************************
>> / void b_tx_rate(uhd::tx_streamer::sptr tx_stream,
>> uhd::time_spec_t start_time, double tx_rate) {
>> uhd::tx_metadata_t md;
>> md.time_spec = start_time;
>> md.has_time_spec = true;
>> // const size_t natural_spp = tx_stream->get_max_num_samps();
>> const size_t min_spp = 200000;//199600; // samples per channel
>> const size_t max_spp = 200000; // samples per channel
>> std::cout << "Using " << max_spp << " samples in send()" << std::endl;
>> std::vector<char> buff(4 * max_spp); // sc16 is 4 bytes per sample
>> const auto num_ch = tx_stream->get_num_channels();
>> std::vector<const void *> pts(num_ch, &buff.front());
>> auto start { NOW }; size_t accum { 0 };
>> while (target > 0) {
>> size_t act_spp = min_spp + (double(rand())/RAND_MAX)*(max_spp - min_spp);
>> if (act_spp > target) act_spp = target;
>> auto rel_time { md.time_spec }; rel_time -= start_time;
>> std::cout << " spp " << act_spp << " alsent " << accum
>> << " to send " << target << " time spec "
>> << rel_time.get_real_secs() << std::endl;
>> start = NOW;
>> auto n = tx_stream->send(pts, act_spp, md);
>> std::cout << "Send call time " << DIF << " sent= " << n << std::endl;
>> accum += n; target -= n;
>> start = NOW;
>> md.time_spec += uhd::time_spec_t::from_ticks(n, tx_rate);
>> md.has_time_spec = false;
>> if (n == 0) { target = 0; break; /* stop on error */ } }
>> md.has_time_spec = false;
>> md.end_of_burst = true; // EOB packet
>> tx_stream->send(pts, 0, md); }
>>
>> /*********************************************************************
>> **
>> * Handle asynchronous messages
>>
>> **********************************************************************
>> / void b_tx_async(uhd::tx_streamer::sptr tx_stream) {
>> uhd::async_metadata_t amd;
>> size_t termination = 10; // delayed exit to catch late messages
>> while (target > 0 || termination > 0) {
>> if (not tx_stream->recv_async_msg(amd)) { // 100ms timeout
>> if (target == 0) --termination; continue; }
>> ++counts[amd.event_code]; } }
>>
>> /*********************************************************************
>> **
>> * Main code + dispatcher
>>
>> **********************************************************************
>> / int UHD_SAFE_MAIN(int argc, char *argv[]){
>> (void)argc; (void)argv;
>> // ---------------------------------------------------------------
>> std::string args { "addr=192.168.30.2,second_addr=192.168.40.2" };
>> std::vector<size_t> tx_channels { 0,1 };
>> double init_delay { 0.5 }; // 500mS
>> double tx_rate { 1.0e6 };
>> // ---------------------------------------------------------------
>> uhd::set_thread_priority_safe();
>> std::cout << "Creating the usrp device with: " << args << std::endl;
>> auto usrp = uhd::usrp::multi_usrp::make(args);
>> std::cout << "Using Device: " << usrp->get_pp_string() << std::endl;
>> usrp->set_tx_rate(tx_rate);
>> //usrp->set_tx_gain(20,0);
>> usrp->set_time_unknown_pps(uhd::time_spec_t(0.0));
>> uhd::stream_args_t stream_args("sc16", "sc16");
>> stream_args.channels = tx_channels;
>> auto tx_stream = usrp->get_tx_stream(stream_args);
>> std::cout << "\nTX subdev_spec=" << usrp->get_tx_subdev_spec().to_string()
>> << "\nTesting tx_rate=" << (usrp->get_tx_rate()/1.0e6) << "MS/s"
>> << " chan=" << tx_stream->get_num_channels() << "\n\n";
>> auto start_time = usrp->get_time_now() + uhd::time_spec_t(init_delay);
>> std::thread tx { b_tx_rate , tx_stream, start_time, tx_rate };
>> std::thread as { b_tx_async, tx_stream };
>> tx.join(); as.join();
>> #define CC(s) std::endl << #s": " << \
>> counts[uhd::async_metadata_t::event_code_t::EVENT_CODE_ ## s]
>> std::cout << CC(BURST_ACK) << CC(UNDERFLOW) << CC(SEQ_ERROR)
>> << CC(TIME_ERROR) << CC(UNDERFLOW_IN_PACKET)
>> << CC(SEQ_ERROR_IN_BURST) << CC(USER_PAYLOAD) << std::endl;
>> return EXIT_SUCCESS; }
>>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 22
Date: Wed, 1 Mar 2017 17:26:40 -0800
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] USRP B200
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
With GNU Radio, you'll pretty much get arbitrary resolution. With a DDS,
it depends on your implementation.
-- M
On 03/01/2017 05:25 PM, Rohit Dilip wrote:
> A couple of further questions, firstly, how is the frequency resolution
> in using the GNURadio solution compared to DDS? Do you have any advice
> on if I wanted to directly reprogram the FPGA and use DDS?
>
> Really appreciate all the help!
------------------------------
Message: 23
Date: Wed, 1 Mar 2017 20:28:41 -0500
From: Rohit Dilip <[email protected]>
To: Martin Braun <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP B200
Message-ID:
<calumccdiw64ffxkj09x54m9n5gnzsfapz9ropvohv-sq73q...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Do you have specific resources for programming a DDS solution with the FPGA?
On Wed, Mar 1, 2017 at 8:26 PM, Martin Braun via USRP-users <
[email protected]> wrote:
> With GNU Radio, you'll pretty much get arbitrary resolution. With a DDS,
> it depends on your implementation.
>
> -- M
>
> On 03/01/2017 05:25 PM, Rohit Dilip wrote:
> > A couple of further questions, firstly, how is the frequency resolution
> > in using the GNURadio solution compared to DDS? Do you have any advice
> > on if I wanted to directly reprogram the FPGA and use DDS?
> >
> > Really appreciate all the help!
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
--
-Rohit Dilip
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170301/251caf38/attachment-0001.html>
------------------------------
Message: 24
Date: Wed, 1 Mar 2017 17:31:51 -0800
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] The difference between the samp_rate in GNU
Radio and Nyquist rate
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Bob,
we tend to avoid the term 'Nyquist Rate' because it often comes up in
DSP 101 classes along with the (incomplete/incorrect) statement that
"the sampling rate must be twice the highest frequency".
Since we're dealing with complex samples, the width of any Nyquist zone
is the sampling rate, i.e., the number of *complex* samples per second.
So, in a B210, let's say you set the sampling rate to 10 MHz, and a
center frequency of 900 MHz. Then, you will get the spectrum from 890
MHz to 910 MHz *in complex baseband*.
A 20 kHz signal won't get picked up with a B210, which goes down to 70
MHz. But let's say it did, you could either set your frequency to 20
kHz, and then you would have you signal at baseband, or you set your
frequency to 0 Hz, and do the mixing in software. Yes, GNU Radio would
let you do that.
-- M
On 02/27/2017 11:33 PM, Bob via USRP-users wrote:
> Hello,
> How to understand the sample rate in the DSP and the sample rate in the
> hardware?
>
> In generally, we use the USRP B210 to receive the RF signal, and finally
> get the baseband signal (the signal carrier frequency is 0Hz)
> and the lower IF signal (assuming the carrier frequency is 20kHz), then
> what are these two cases of Nyquist rate?
>
> And, then use USRP B210 to process this signal, and what is the sample
> rate in the block? Is it Nyquist rate?
>
> Finally, If a low-IF signal with a carrier frequency of 20 kHZ is
> down-converted to a baseband signal (carrier frequency 0 Hz),
> is it possible to implement blocks in GNU Radio using the C ++ language?
>
> Thank you very much for your answers. I am looking forward to your
> reply as soon as possible and as detailed as possible.
> Thanks!
>
> Bob
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 25
Date: Wed, 1 Mar 2017 17:46:26 -0800
From: Nate Temple <[email protected]>
To: Martin Braun <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: [USRP-users] The difference between the samp_rate in GNU
Radio and Nyquist rate
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi Bob,
Just clarifying a value in Martin's reply:
"So, in a B210, let's say you set the sampling rate to 10 MHz, and a
center frequency of 900 MHz. Then, you will get the spectrum from 890
MHz to 910 MHz *in complex baseband*."
Should be "sampling rate to 20 MHz..." for that example.
Regards,
Nate
> On Mar 1, 2017, at 5:31 PM, Martin Braun via USRP-users
> <[email protected]> wrote:
>
> Bob,
>
> we tend to avoid the term 'Nyquist Rate' because it often comes up in
> DSP 101 classes along with the (incomplete/incorrect) statement that
> "the sampling rate must be twice the highest frequency".
>
> Since we're dealing with complex samples, the width of any Nyquist zone
> is the sampling rate, i.e., the number of *complex* samples per second.
>
> So, in a B210, let's say you set the sampling rate to 10 MHz, and a
> center frequency of 900 MHz. Then, you will get the spectrum from 890
> MHz to 910 MHz *in complex baseband*.
>
> A 20 kHz signal won't get picked up with a B210, which goes down to 70
> MHz. But let's say it did, you could either set your frequency to 20
> kHz, and then you would have you signal at baseband, or you set your
> frequency to 0 Hz, and do the mixing in software. Yes, GNU Radio would
> let you do that.
>
> -- M
>
> On 02/27/2017 11:33 PM, Bob via USRP-users wrote:
>> Hello,
>> How to understand the sample rate in the DSP and the sample rate in the
>> hardware?
>>
>> In generally, we use the USRP B210 to receive the RF signal, and finally
>> get the baseband signal (the signal carrier frequency is 0Hz)
>> and the lower IF signal (assuming the carrier frequency is 20kHz), then
>> what are these two cases of Nyquist rate?
>>
>> And, then use USRP B210 to process this signal, and what is the sample
>> rate in the block? Is it Nyquist rate?
>>
>> Finally, If a low-IF signal with a carrier frequency of 20 kHZ is
>> down-converted to a baseband signal (carrier frequency 0 Hz),
>> is it possible to implement blocks in GNU Radio using the C ++ language?
>>
>> Thank you very much for your answers. I am looking forward to your
>> reply as soon as possible and as detailed as possible.
>> Thanks!
>>
>> Bob
>>
>>
>>
>> _______________________________________________
>> 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
------------------------------
Message: 26
Date: Thu, 2 Mar 2017 08:31:09 +0300
From: do ber <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Wireless data transfer
Message-ID:
<CABLDF_c_sF2DCweQn4PjY=ymfm0km4bpjcbz+zz8rugiu5g...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
@Marcus, I need 4 channels and each channel will operate with a sampling
rate of 1MHz.
@Julian, I never used LTE modems. From what you said, I understand that I
can communicate and receive data from USRPs by using LTE modems? If it is
true, then I need to learn how to do that.
@Julian, yes I need to start the experiment at all locations at the same
time. So I am thinking only ONE computer controlling 2 USRPs. But somehow I
need to get the I/Q data recorded at the same time interval. I did not
unterstand what you mean by imlpying storing at local machines? Actually,
the second option you said seems to be more convenient to my problem.
I want to start and stop 4 channels at the same time. Then I will analyze
the stored I/Q data OFFLINE. To be more specific, I want to implement a
localization algorithm. So I need I/Q data from 4 channels and they must be
synchronized in time and frequency. So it is important that USRPs start and
stop recording data at the same time.
Another option may be recording samples with their TIME TAGs. I mean at
what time they are recorded. So may be then I can start two USRPs with the
help of a friend. Then I can analyze the data by inspecting their time
tags. But it would not be professional and I do not know is it possible in
GNURadio. Also, adding time tag to communication will decrease the channel
capacity.
Thanks,
Ali
2017-03-01 14:13 GMT+03:00 Julian Arnold <[email protected]>:
> Hey,
>
> If I understood it correctly he only needs a control channel to start the
> experiment at all locations at the same time. The actual data is then
> stored on the local machines. Or did I get that wrong?
> Streaming the whole data to a central location would of course be a
> completely different story.
>
> Cheers,
>
> Julian Arnold, M.Sc
>
> On 1 Mar 2017, at 10:55, Marcus M?ller <[email protected]> wrote:
>
> I'd like to agree with Julian here. IQ data is typically very high-rate,
> and you must tell us which rates you need to achieve on your six channels
> before we can recommend anything.
>
> Also note that the x3x0 has pretty universally compatible 10 gigabit
> Ethernet SFP+ ports, so the most intuitive way would simply be coming up
> with a dedicated fibre optic network based e.g. on 10 GBase-LR.
>
> Best regards,
> Marcus
>
> Am 1. M?rz 2017 09:29:33 MEZ schrieb Julian Arnold via USRP-users <
> [email protected]>:
>>
>> Hi Ali,
>>
>> I could imagine that using something like LTE modems in the PCs
>> controlling the USRPs could be a quick way to get a control channel up
>> and running.
>> Also, you could of course try to use the USRPs themselves to establish
>> the control channel. However, I think this would be more involved than
>> using an existing mobile network.
>>
>> Cheers,
>> Julian
>>
>> On 03/01/2017 06:24 AM, do ber via USRP-users wrote:
>>
>>> Hi,
>>>
>>> I think I explained my problem in a wrong way. I am normally using GNU
>>> radio and I can synchronize them by using GPSDO. So far there is no
>>> problem.
>>>
>>> Lets say there is 1km distance between 2 USRPs. What I am asking is how
>>> can I start two distant USRP's from one computer. How can I get the I/Q
>>> data from them. For example, can I control them via a kind of dongle
>>> instead of an ethernet cable?
>>>
>>> In other words, I am saying that the USRPs are far away from me and I
>>> cannot use cables. Is there a wireless solution?
>>>
>>> Best regards,
>>> Ali
>>>
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170302/344f941d/attachment-0001.html>
------------------------------
Message: 27
Date: Wed, 1 Mar 2017 23:09:11 -0500
From: Yutong Liu <[email protected]>
To: <[email protected]>
Subject: [USRP-users] on-off keying modulation and demodulation
Message-ID:
<CAGuW==f57gvLOZ=Pp3zSuZ13u=ESX_Z-7pQPVOh+pAedsUT=f...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I am not familiar with signal processing and the question may seem to be
stupid. I wonder how can I generate a signal with pulse width smaller than
0.1 us and center frequency equals to 1.3 GHz. I am using Ettus b210 board
and gnuradio as the software. The maximum allowable bandwidth of the UHD
sink is 56 MHz. Previously, I used a RF switch to perform such modulation.
Both carrier RF signals and baseband signals were continuous and coming
directly from the function generator. How can I modulate the 1.3 GHz RF
signal with a 52 MHz sample rate and 5.2MHz frequency baseband square wave?
When I connected the square wave (coming form the signal source) to UHD
sink and set the center frequency to be 1.3 GHz, the center frequency shown
at the oscilloscope was 1.3 GHz. However, the shape of the output envelope
was not a square wave (as shown in my drawing). Is there an explanation to
such distortion? How can I get the desiring signal?
Eventually, I will need to connect the transmitter to a transducer, and
receive the acoustic wave from the transducer. The process is basically an
on-off keying modulation and demodulation. I wonder how can I receive such
signal with UHD source? I tested the receiver with the modulated signal
from the RF switch, but the received signal at the WX sink was just noise.
I am not sure which filter or demod module I should use.
I am very appreciated for your help.
Regards.
Yutong
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170301/e9830bb1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: output.jpeg
Type: image/jpeg
Size: 1498865 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170301/e9830bb1/attachment-0001.jpeg>
------------------------------
Message: 28
Date: Thu, 2 Mar 2017 10:52:56 +0300
From: do ber <[email protected]>
To: [email protected]
Subject: [USRP-users] X310-PCIe connection in Linux
Message-ID:
<cabldf_eubb5urgmwg16e1cykehvqujok1jawr-x-lkrjeza...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi to all,
I want to work with a wideband signal. The bandwidth will be very high (I
will push the limits). I have X310, UBX-160 and PCI-Express Connectivity
Kit (PCIe ? Desktop) <https://www.ettus.com/product/details/PCIE-KIT>.
There is Intel 8 series/C220 chipset in my desktop computer.
I searched the Ettus' website and find this
<https://files.ettus.com/manual/page_ni_rio_kernel.html>.
** In Windows Labview 2015
When I run NI USRP-Configuration Utility, I get:
Device ID: RIO0
Connection: PCIe
Type/Revision: X310/UBX-160 v1/rev8
Then I run an example program and get the error:
USRP RIO: Hardware is too new for this version of the Configuration
Instrument Design Library.
Anyway, I already know that Labview does not support UBX card. So I left
working on Labview. Actually, I do not know much about Labview.
**In Linux
I installed the given NI USRPRIO kernels. When I write the
"uhd_usrp_probe", UHD sees the device.
...
-- Connecting to niusrpriopc at localhost:5444...
...
So it is working. But then, how can I use USRP in Linux? I actually want to
work with GNURadio. Is it possible to work on GNURadio with PCIe
connection? Or do I have to write in Python? I did not see any example of
usage in Linux on the internet.
In short, please tell me how can I record I/Q data of a wideband signal
with PCIe connection in Linux, prefferably by GNURadio?
Best regards,
Ali
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170302/eb68f091/attachment-0001.html>
------------------------------
Message: 29
Date: Thu, 2 Mar 2017 08:53:42 +0000
From: Crozzoli Maurizio <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] R: Install uhd on Raspberry Pi 3
Message-ID:
<5fe5e9f99181437e9e677c90895bc495@TELMBXD10BA020.telecomitalia.local>
Content-Type: text/plain; charset="iso-8859-1"
srsLTE
-----Messaggio originale-----
Da: USRP-users [mailto:[email protected]] Per conto di Martin
Braun via USRP-users
Inviato: gioved? 2 marzo 2017 01:36
A: [email protected]
Oggetto: Re: [USRP-users] Install uhd on Raspberry Pi 3
uhd::msg was removed on master branch recently (see my post with subject
"Logging Infrastructure changes on master branch"). What's the software you're
compiling?
-- M
On 03/01/2017 03:15 PM, Disco Daniele via USRP-users wrote:
> Hi!
>
> In these days I'm trying to install the uhd library on Raspberry Pi 3
> Model B.
>
> Starting from
>
> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Tool
> chain_(UHD_and_GNU_Radio)_on_Linux
> <https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Too
> lchain_%28UHD_and_GNU_Radio%29_on_Linux>, I used like image for the Pi ubuntu
> mate.
>
> Is a porting of ubuntu for the Pi with version 16.04.
>
> I erased all the applications non
> necessary, upgraded the distribution and installed all the application
> reported for 16.04 (fyi some packages are reported twice like
> doxygen).
>
> Than I used the uhd-master version (using the download from uhd github
> site) and at the end I installed uhd.
>
> Running the tests no error was reported.
>
> Than I compiled another sw that use the namespace uhd::msg and it
> failed because the namespace in the master is not present (if you look
> in /usr/local/include/uhd/utils/msg.hpp is not present).
>
>
> Looking in the repository I verified that in the master distribution
> this header file is not present but in the other releases (like the
> last
> one) this header is present.
>
>
> So using the procedure
>
> git clone https://github.com/EttusResearch/uhd
> cd uhd
>
> git checkout release_00X_00y_00z
>
> I download the last release of uhd. I ported this directory on
> raspberry pi and the compilation goes on just to build the uhd.so
> library.
>
> Then compiling the first of test example the code crash for errors.
>
> Please, could you help me to solve this strange case?
> Thank you
> Daniele
> PS: If I'm interested only on uhd but not in gnuradio, it is possible
> to separate in the page
> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Tool
> chain_(UHD_and_GNU_Radio)_on_Linux
> <https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Too
> lchain_%28UHD_and_GNU_Radio%29_on_Linux>,
>
> the apps/libs necessary for uhd respect to the apps/libs necessary to
> gnuradio.
> Thank you again
>
>
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente
> alle persone indicate. La diffusione, copia o qualsiasi altra azione
> derivante dalla conoscenza di queste informazioni sono rigorosamente
> vietate. Qualora abbiate ricevuto questo documento per errore siete
> cortesemente pregati di darne immediata comunicazione al mittente e di
> provvedere alla sua distruzione, Grazie.
>
> /This e-mail and any attachments// is //confidential and may contain
> privileged information intended for the addressee(s) only.
> Dissemination, copying, printing or use by anybody else is unauthorised.
> If you are not the intended recipient, please delete this message and
> any attachments and advise the sender by return e-mail, Thanks./
>
> *rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se
> non ? necessario.*
>
>
>
> _______________________________________________
> 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
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone
indicate. La diffusione, copia o qualsiasi altra azione derivante dalla
conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate
ricevuto questo documento per errore siete cortesemente pregati di darne
immediata comunicazione al mittente e di provvedere alla sua distruzione,
Grazie.
This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intended
recipient, please delete this message and any attachments and advise the sender
by return e-mail, Thanks.
------------------------------
Message: 30
Date: Thu, 2 Mar 2017 09:58:10 +0100
From: Julian Arnold <[email protected]>
To: do ber <[email protected]>, [email protected]
Subject: Re: [USRP-users] Wireless data transfer
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hey,
okay, so I got you wrong. I thought you have two USRPs separated by a
large distance and that each USRP has its own PC/laptop controlling it.
Therefore, I suggested using LTE on the laptops to start the flow-graphs.
However, if you only have one PC then you will have to run long cables
to the USRPs as they have to get controlled somehow unless you are using
E-series devices?
Cheers,
Julian
On 03/02/2017 06:31 AM, do ber via USRP-users wrote:
> Hi,
>
> @Marcus, I need 4 channels and each channel will operate with a sampling
> rate of 1MHz.
>
> @Julian, I never used LTE modems. From what you said, I understand that
> I can communicate and receive data from USRPs by using LTE modems? If it
> is true, then I need to learn how to do that.
>
> @Julian, yes I need to start the experiment at all locations at the same
> time. So I am thinking only ONE computer controlling 2 USRPs. But
> somehow I need to get the I/Q data recorded at the same time interval. I
> did not unterstand what you mean by imlpying storing at local machines?
> Actually, the second option you said seems to be more convenient to my
> problem.
>
> I want to start and stop 4 channels at the same time. Then I will
> analyze the stored I/Q data OFFLINE. To be more specific, I want to
> implement a localization algorithm. So I need I/Q data from 4 channels
> and they must be synchronized in time and frequency. So it is important
> that USRPs start and stop recording data at the same time.
>
> Another option may be recording samples with their TIME TAGs. I mean at
> what time they are recorded. So may be then I can start two USRPs with
> the help of a friend. Then I can analyze the data by inspecting their
> time tags. But it would not be professional and I do not know is it
> possible in GNURadio. Also, adding time tag to communication will
> decrease the channel capacity.
>
> Thanks,
> Ali
>
>
> 2017-03-01 14:13 GMT+03:00 Julian Arnold <[email protected]
> <mailto:[email protected]>>:
>
> Hey,
>
> If I understood it correctly he only needs a control channel to
> start the experiment at all locations at the same time. The actual
> data is then stored on the local machines. Or did I get that wrong?
> Streaming the whole data to a central location would of course be a
> completely different story.
>
> Cheers,
>
> Julian Arnold, M.Sc
>
> On 1 Mar 2017, at 10:55, Marcus M?ller <[email protected]
> <mailto:[email protected]>> wrote:
>
>> I'd like to agree with Julian here. IQ data is typically very
>> high-rate, and you must tell us which rates you need to achieve on
>> your six channels before we can recommend anything.
>>
>> Also note that the x3x0 has pretty universally compatible 10
>> gigabit Ethernet SFP+ ports, so the most intuitive way would
>> simply be coming up with a dedicated fibre optic network based
>> e.g. on 10 GBase-LR.
>>
>> Best regards,
>> Marcus
>>
>> Am 1. M?rz 2017 09:29:33 MEZ schrieb Julian Arnold via USRP-users
>> <[email protected] <mailto:[email protected]>>:
>>
>> Hi Ali,
>>
>> I could imagine that using something like LTE modems in the PCs
>> controlling the USRPs could be a quick way to get a control channel
>> up
>> and running.
>> Also, you could of course try to use the USRPs themselves to
>> establish
>> the control channel. However, I think this would be more involved
>> than
>> using an existing mobile network.
>>
>> Cheers,
>> Julian
>>
>> On 03/01/2017 06:24 AM, do ber via USRP-users wrote:
>>
>> Hi,
>>
>> I think I explained my problem in a wrong way. I am
>> normally using GNU
>> radio and I can synchronize them by using GPSDO. So far
>> there is no
>> problem.
>>
>> Lets say there is 1km distance between 2 USRPs. What I am
>> asking is how
>> can I start two distant USRP's from one computer. How can
>> I get the I/Q
>> data from them. For example, can I control them via a kind
>> of dongle
>> instead of an ethernet cable?
>>
>> In other words, I am saying that the USRPs are far away
>> from me and I
>> cannot use cables. Is there a wireless solution?
>>
>> Best regards,
>> Ali
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
--
Julian Arnold, M.Sc.
Institute for Networked Systems
RWTH Aachen University
Kackertstrasse 9
52072 Aachen
Germany
------------------------------
Message: 31
Date: Thu, 2 Mar 2017 10:37:04 +0100
From: Sebastian Mueller <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RuntimeError: basic_string::_M_construct
null not valid when using RFNoC:Radio
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Yep Device3 block is there. I've attached a screenshot.
On 01.03.2017 20:11, Jason Matusiak wrote:
> Sebastian, do you have a Device3 block in your flowgraph (maybe post a
> screenshot of your flowgraph)?
>
> On 03/01/2017 12:14 PM, Sebastian Mueller via USRP-users wrote:
>> Hi list,
>>
>> I'm currently trying to get a very basic RFNoC flowgraph running that
>> looks like this:
>>
>> [RFNoC: Radio] -> [RFNoC: DDC] -> [RFNoC: DmaFIFO] -> [QT GUI Frequency
>> Sink]
>>
>> When I try to run it, I get the following error:
>>
>> Traceback (most recent call last):
>> File "/home/user/src/rfnoc/examples/top_block.py", line 307, in
>> <module>
>> main()
>> File "/home/user/src/rfnoc/examples/top_block.py", line 295, in main
>> tb = top_block_cls()
>> File "/home/user/src/rfnoc/examples/top_block.py", line 90, in
>> __init__
>> 0, -1
>> File "/usr/local/lib/python2.7/dist-packages/ettus/ettus_swig.py",
>> line 2706, in make
>> return _ettus_swig.rfnoc_radio_make(dev, tx_stream_args,
>> rx_stream_args, radio_select, device_select)
>> RuntimeError: basic_string::_M_construct null not valid
>>
>> I have tried with Swig version 2.0.4 as well as 3.0.8 with the same
>> result. Also, I have switched DDC with DmaFIFO with no success.
>> UHD, gr-ettus and fpga are all newest versions from GitHub repos. Any
>> idea how I can fix this error?
>>
>> Cheers,
>> Sebastian
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rfnoc_fg.png
Type: image/png
Size: 95014 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170302/204f0bc4/attachment-0001.png>
------------------------------
Message: 32
Date: Thu, 2 Mar 2017 11:56:18 +0100
From: Paolo Palana <[email protected]>
To: [email protected]
Subject: [USRP-users] X310: who generate overflow and dropped packet
messages?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi to all,
I'm working on my project with the X310 SDR. This project include a
custom RFNoc block.
Now I have a couple of question about the generation of inline messages
related with overflow (O) and dropped packet (D).
In order to generate an overflow I'm recording data (at a high sample
rate, say 200Msps) coming through a 10GB ethernet on a file.
If I record data using only the DDC block I have an overflow, and that
is good, because the HD is too slow to record data at the target rate.
If after the DDC I "connect" my block the overflow messages disappear,
and that is bad, because my block is essentially a pipeline and consume
packets on a 1/1 ratio.
What I would ask is:
1) who is responsible for generate the overflow (and dropped) messages?
Reading the libuhd c++ code seem like the generation of this messages is
on the FPGA, but reading the verilog source code I'm unable to pinpoint
who is generating them.
2) these messages are automatically propagated through the DSP chain, or
I must take special care, on my block, in order to forward them to the host?
3) can I generate this kind of messages from my block, e.g. to signal
"strange things" appening in my block to the host?
Thank you
Have a good day
Paolo
------------------------------
Message: 33
Date: Thu, 2 Mar 2017 12:52:37 +0100
From: Julian Arnold <[email protected]>
To: Yutong Liu <[email protected]>, [email protected]
Subject: Re: [USRP-users] on-off keying modulation and demodulation
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Yutong,
> Is there an explanation to such distortion? How
> can I get the desiring signal?
The problem is, that to represent a perfect square wave you would need
an infinite bandwidth due to the steps in the rectangular pulses.
However, the bandwidth of the USRP (and basically every other hardware
device) is limited. Therefore, in order to avoid surprises you should
band-limit your signal before transmission.
Usually you would start with a train of pulses and then use
pulse-shaping [1] to generate your baseband waveform.
You basically filter your signal with a filter that band-limits you
signal and also allows the receiver to reconstruct the pulses in a noisy
environment (matched filtering) without ISI.
There are some pulse-shapes that are commonly used like the
root-raised-cosine filter shape [2] and that are also supported by GNU
Radio [3].
Also, if I'm not wrong, the digital modulation blocks from GNU Radio
should already include pulse shaping. So if you use one of those you
should be good.
So, don't worry if your signal does not look perfect. It can't because
it gets band-limited by the hardware.
If you need more info, let me know.
[2] https://en.wikipedia.org/wiki/Root-raised-cosine_filter
[1] https://en.wikipedia.org/wiki/Pulse_shaping
[3]
http://gnuradio.org/doc/doxygen/classgr_1_1filter_1_1firdes.html#af37a0f8f92f1e0440033ccdb118df990
Cheers,
Julian
On 03/02/2017 05:09 AM, Yutong Liu via USRP-users wrote:
> Hi,
>
> I am not familiar with signal processing and the question may seem to be
> stupid. I wonder how can I generate a signal with pulse width smaller
> than 0.1 us and center frequency equals to 1.3 GHz. I am using Ettus
> b210 board and gnuradio as the software. The maximum allowable bandwidth
> of the UHD sink is 56 MHz. Previously, I used a RF switch to perform
> such modulation. Both carrier RF signals and baseband signals were
> continuous and coming directly from the function generator. How can I
> modulate the 1.3 GHz RF signal with a 52 MHz sample rate and 5.2MHz
> frequency baseband square wave? When I connected the square wave (coming
> form the signal source) to UHD sink and set the center frequency to be
> 1.3 GHz, the center frequency shown at the oscilloscope was 1.3 GHz.
> However, the shape of the output envelope was not a square wave (as
> shown in my drawing). Is there an explanation to such distortion? How
> can I get the desiring signal?
>
> Eventually, I will need to connect the transmitter to a transducer, and
> receive the acoustic wave from the transducer. The process is basically
> an on-off keying modulation and demodulation. I wonder how can I receive
> such signal with UHD source? I tested the receiver with the modulated
> signal from the RF switch, but the received signal at the WX sink was
> just noise. I am not sure which filter or demod module I should use.
>
> I am very appreciated for your help.
>
> Regards.
> Yutong
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
--
Julian Arnold, M.Sc.
Institute for Networked Systems
RWTH Aachen University
Kackertstrasse 9
52072 Aachen
Germany
------------------------------
Message: 34
Date: Thu, 2 Mar 2017 12:50:07 +0000
From: Stefano Bettelli <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310: who generate overflow and dropped
packet messages?
Message-ID: <1C28F8990859A84D809CFC7AB0D38942A85530@lhreml502-mbx>
Content-Type: text/plain; charset="us-ascii"
Hi
>> 1) who is responsible for generate the overflow (and dropped) messages?
The messages are generated inside the function get_aligned_buffs() in
<UHD_ROOT>/host/lib/transport/super_recv_packet_handler.hpp and sent to the
UHD_MSG(fastpath) stream.
You can even intercept them if you provide a callback with
uhd::msg::register_handler.
I would assume that the error conditions are detected by the part of the UHD
system that resides in your PC, not by the FPGA, but I may be wrong.
------------------------------
Message: 35
Date: Thu, 2 Mar 2017 08:16:53 -0500
From: Jason Matusiak <[email protected]>
To: [email protected], "Marcus D. Leech" <[email protected]>
Subject: Re: [USRP-users] B205mini power usage
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
OK, thanks, that helps. In my case, I am not even running a flowgraph,
so I would imagine that my power draw would be even less that the 1 RX
5Msps option in that table. So in my mind it should be drawing <=
400mA, which should be within spec (unless there is some sort of in-rush
happening that is throwing off the internal USB on the phone).
There aren't complete schematics out there, but I /think/ that the
controller going to this connector is this TI part:
http://www.ti.com/product/HD3SS460/description, but I can't seem to find
out how they are supplying power to the connector itself (which is my
gut for where the issue is). If I can find a powered USB3 hub, I will
give that a try, but I don't think that we have any lying around at work....
~Jason
On 03/01/2017 03:27 PM, Marcus D. Leech via USRP-users wrote:
> On 03/01/2017 03:06 PM, Jason Matusiak via USRP-users wrote:
>> Are there any documentation listed anywhere on the mini's power draw?
>>
>> I am attempting to get it to enumerate on a phone and the power light
>> comes on, but Android on some (not all) phones doesn't enumerate it.
>> It makes me wonder if maybe it is trying to draw too much power for
>> the phone to handle comfortably. I am using the full USB3 connector
>> to a USB-OTG C adapter to the phone.
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> There's a power-consumption table for B210 here which can give you a
> rough idea:
>
> https://kb.ettus.com/B200/B210/B200mini/B205mini
>
> But if it's not enumerating, the sounds like a controller issue.
>
>
>
> _______________________________________________
> 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/20170302/096a57a9/attachment-0001.html>
------------------------------
Message: 36
Date: Thu, 2 Mar 2017 08:28:09 -0500
From: Jason Matusiak <[email protected]>
To: Sebastian Mueller <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] RuntimeError: basic_string::_M_construct
null not valid when using RFNoC:Radio
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Darn, I was hoping that that was the missing piece.
I don't have DmaFIFO in my current FPGA image, so I wasn't able to do
your exact test, but if I replaced DmaFIFO with the regular RFNoC:FIFO,
it ran fine. I know that that is different, but if you swap out that
block, does it suddenly work?
On 03/02/2017 04:37 AM, Sebastian Mueller via USRP-users wrote:
> Yep Device3 block is there. I've attached a screenshot.
>
>
> On 01.03.2017 20:11, Jason Matusiak wrote:
>> Sebastian, do you have a Device3 block in your flowgraph (maybe post a
>> screenshot of your flowgraph)?
>>
>> On 03/01/2017 12:14 PM, Sebastian Mueller via USRP-users wrote:
>>> Hi list,
>>>
>>> I'm currently trying to get a very basic RFNoC flowgraph running that
>>> looks like this:
>>>
>>> [RFNoC: Radio] -> [RFNoC: DDC] -> [RFNoC: DmaFIFO] -> [QT GUI Frequency
>>> Sink]
>>>
>>> When I try to run it, I get the following error:
>>>
>>> Traceback (most recent call last):
>>> File "/home/user/src/rfnoc/examples/top_block.py", line 307, in
>>> <module>
>>> main()
>>> File "/home/user/src/rfnoc/examples/top_block.py", line 295, in main
>>> tb = top_block_cls()
>>> File "/home/user/src/rfnoc/examples/top_block.py", line 90, in
>>> __init__
>>> 0, -1
>>> File "/usr/local/lib/python2.7/dist-packages/ettus/ettus_swig.py",
>>> line 2706, in make
>>> return _ettus_swig.rfnoc_radio_make(dev, tx_stream_args,
>>> rx_stream_args, radio_select, device_select)
>>> RuntimeError: basic_string::_M_construct null not valid
>>>
>>> I have tried with Swig version 2.0.4 as well as 3.0.8 with the same
>>> result. Also, I have switched DDC with DmaFIFO with no success.
>>> UHD, gr-ettus and fpga are all newest versions from GitHub repos. Any
>>> idea how I can fix this error?
>>>
>>> Cheers,
>>> Sebastian
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20170302/834e51fd/attachment-0001.html>
------------------------------
Message: 37
Date: Thu, 02 Mar 2017 10:26:30 -0500
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] X310-PCIe connection in Linux
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 03/02/2017 02:52 AM, do ber via USRP-users wrote:
> Hi to all,
>
> I want to work with a wideband signal. The bandwidth will be very high
> (I will push the limits). I have X310, UBX-160 and PCI-Express
> Connectivity Kit (PCIe ? Desktop)
> <https://www.ettus.com/product/details/PCIE-KIT>. There is Intel 8
> series/C220 chipset in my desktop computer.
>
> I searched the Ettus' website and find this
> <https://files.ettus.com/manual/page_ni_rio_kernel.html>.
>
> ** In Windows Labview 2015
> When I run NI USRP-Configuration Utility, I get:
> Device ID: RIO0
> Connection: PCIe
> Type/Revision: X310/UBX-160 v1/rev8
>
> Then I run an example program and get the error:
> USRP RIO: Hardware is too new for this version of the Configuration
> Instrument Design Library.
>
> Anyway, I already know that Labview does not support UBX card. So I
> left working on Labview. Actually, I do not know much about Labview.
>
> **In Linux
> I installed the given NI USRPRIO kernels. When I write the
> "uhd_usrp_probe", UHD sees the device.
> ...
> -- Connecting to niusrpriopc at localhost:5444...
> ...
>
> So it is working. But then, how can I use USRP in Linux? I actually
> want to work with GNURadio. Is it possible to work on GNURadio with
> PCIe connection? Or do I have to write in Python? I did not see any
> example of usage in Linux on the internet.
>
> In short, please tell me how can I record I/Q data of a wideband
> signal with PCIe connection in Linux, prefferably by GNURadio?
>
> Best regards,
> Ali
>
If you just want to record, you can use the 'uhd_rx_cfile' utility that
is part of Gnu Radio.
You can also use 'rx_samples_to_file' that is part of UHD.
Be aware that making high-bandwidth recording work requires both a FAST
computer, and a suitable SSD-based disk subsystem.
In either case, you'd just specify "resource=RIO0" in the device
arguments when using the UHD utilities, or Gnu Radio programs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170302/4461bf2a/attachment-0001.html>
------------------------------
Message: 38
Date: Thu, 2 Mar 2017 17:30:03 +0100
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Wireless data transfer
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Ali,
so, ok, what you need is pretty clearly a computer at every USRP,
because for 1MS/s, you'll need to transport 32 Mb/s ? and that's
typically a lot more than you can cheaply transfer over wireless
networks (i.e. WiFi or LTE). You record the data on these computers,
they don't have to be strong for these rates, and then collected the
data later on.
You coordinate the start of all the USRPs as discussed by synchronizing
device to GPS time and using the same timed command on every device.
Since the time in the timed command needs to be the same for every
computer, the easiest way seems to be to equip every computer with just
any cellular (2G, 3G, LTE, whatever) network access (i.e. a cellular
modem), and send the times to the computers by having some really simple
program on your computers that ask for the times to start and stop
recording from a central server (eg. very simply using SSH).
Best regards,
Marcus
On 03/02/2017 06:31 AM, do ber via USRP-users wrote:
> Hi,
>
> @Marcus, I need 4 channels and each channel will operate with a
> sampling rate of 1MHz.
>
> @Julian, I never used LTE modems. From what you said, I understand
> that I can communicate and receive data from USRPs by using LTE
> modems? If it is true, then I need to learn how to do that.
>
> @Julian, yes I need to start the experiment at all locations at the
> same time. So I am thinking only ONE computer controlling 2 USRPs. But
> somehow I need to get the I/Q data recorded at the same time interval.
> I did not unterstand what you mean by imlpying storing at local
> machines? Actually, the second option you said seems to be more
> convenient to my problem.
>
> I want to start and stop 4 channels at the same time. Then I will
> analyze the stored I/Q data OFFLINE. To be more specific, I want to
> implement a localization algorithm. So I need I/Q data from 4 channels
> and they must be synchronized in time and frequency. So it is
> important that USRPs start and stop recording data at the same time.
>
> Another option may be recording samples with their TIME TAGs. I mean
> at what time they are recorded. So may be then I can start two USRPs
> with the help of a friend. Then I can analyze the data by inspecting
> their time tags. But it would not be professional and I do not know is
> it possible in GNURadio. Also, adding time tag to communication will
> decrease the channel capacity.
>
> Thanks,
> Ali
>
>
> 2017-03-01 14:13 GMT+03:00 Julian Arnold <[email protected]
> <mailto:[email protected]>>:
>
> Hey,
>
> If I understood it correctly he only needs a control channel to
> start the experiment at all locations at the same time. The actual
> data is then stored on the local machines. Or did I get that wrong?
> Streaming the whole data to a central location would of course be
> a completely different story.
>
> Cheers,
>
> Julian Arnold, M.Sc
>
> On 1 Mar 2017, at 10:55, Marcus M?ller <[email protected]
> <mailto:[email protected]>> wrote:
>
>> I'd like to agree with Julian here. IQ data is typically very
>> high-rate, and you must tell us which rates you need to achieve
>> on your six channels before we can recommend anything.
>>
>> Also note that the x3x0 has pretty universally compatible 10
>> gigabit Ethernet SFP+ ports, so the most intuitive way would
>> simply be coming up with a dedicated fibre optic network based
>> e.g. on 10 GBase-LR.
>>
>> Best regards,
>> Marcus
>>
>> Am 1. M?rz 2017 09:29:33 MEZ schrieb Julian Arnold via USRP-users
>> <[email protected] <mailto:[email protected]>>:
>>
>> Hi Ali,
>>
>> I could imagine that using something like LTE modems in the PCs
>> controlling the USRPs could be a quick way to get a control channel
>> up
>> and running.
>> Also, you could of course try to use the USRPs themselves to
>> establish
>> the control channel. However, I think this would be more involved
>> than
>> using an existing mobile network.
>>
>> Cheers,
>> Julian
>>
>> On 03/01/2017 06:24 AM, do ber via USRP-users wrote:
>>
>> Hi, I think I explained my problem in a wrong way. I am
>> normally using GNU radio and I can synchronize them by
>> using GPSDO. So far there is no problem. Lets say there
>> is 1km distance between 2 USRPs. What I am asking is how
>> can I start two distant USRP's from one computer. How can
>> I get the I/Q data from them. For example, can I control
>> them via a kind of dongle instead of an ethernet cable?
>> In other words, I am saying that the USRPs are far away
>> from me and I cannot use cables. Is there a wireless
>> solution? Best regards, Ali
>>
>> ------------------------------------------------------------------------
>> USRP-users mailing list [email protected]
>> <mailto:[email protected]>
>>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>
>>
>> -- Sent from my Android device with K-9 Mail. Please excuse my
>> brevity.
>
> _______________________________________________
> 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/20170302/6b74acc2/attachment-0001.html>
------------------------------
Message: 39
Date: Thu, 2 Mar 2017 17:34:23 +0100
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP B200
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Rohit,
that pretty much boils down to a complete introduction to HDL programming.
As Martin repeatedly said, there's simply no good reason to do this in
the FPGA. Especially, there's mathematically and technically absolutely
no difference between running the signal synthesis in your computer
(which was what Ettus had in mind when designing the B200) and doing it
in the FPGA. It's all just a series of numbers, and numbers don't care
*where* they get calculated.
Also, have a look at the offset tuning that every USRP offers. I don't
even think you need to write a single line of code to generate what you
want, but to be fair, I think we're all still pretty confused by why you
insist on doing this in the FPGA. It just seems technologically unwise.
Best regards,
Marcus
On 03/02/2017 02:28 AM, Rohit Dilip via USRP-users wrote:
> Do you have specific resources for programming a DDS solution with the
> FPGA?
>
> On Wed, Mar 1, 2017 at 8:26 PM, Martin Braun via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> With GNU Radio, you'll pretty much get arbitrary resolution. With
> a DDS,
> it depends on your implementation.
>
> -- M
>
> On 03/01/2017 05:25 PM, Rohit Dilip wrote:
> > A couple of further questions, firstly, how is the frequency
> resolution
> > in using the GNURadio solution compared to DDS? Do you have any
> advice
> > on if I wanted to directly reprogram the FPGA and use DDS?
> >
> > Really appreciate all the help!
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>
>
>
>
> --
> -Rohit Dilip
>
>
> _______________________________________________
> 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/20170302/b435ed12/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 79, Issue 2
*****************************************
