from:"Hojoon Yang via USRP\-users"

[USRP-users] timeout in tx_timed_samples

2017-11-08 Thread Hojoon Yang via USRP-users

Hi all,In the example tx_timed_samples.cppthere is tx_stream->send(... , ... , 
..., timeout)How the timeout works?when I set the value of timeout zero or 
0.1, I expect that the terminal show the "Send timeout..."because it will 
not have enough time to send all samples during timeout 0.(I expect that it 
will send 0 samples)it will timeout before entire transmission of samples..But 
seems that it works perfectly.. it prints out Sent packet : 2044 which is the 
maximum value of samples..How the timeout works!?!?Thanks in advance!!  
size_t num_acc_samps = 0; //number of accumulated samples 
while(num_acc_samps < total_num_samps){ size_t samps_to_send = 
std::min(total_num_samps - num_acc_samps, buff.size());  //send a 
single packet size_t num_tx_samps = tx_stream->send( 
&buff.front(), samps_to_send, md, timeout );  //do not use time 
spec for subsequent packets md.has_time_spec = false;  if 
(num_tx_samps < samps_to_send) std::cerr << "Send timeout..." << std::endl; 
    if(verbose) std::cout << boost::format("Sent packet: %u samples") % 
num_tx_samps << std::endl;  num_acc_samps += num_tx_samps; }    
  //send a mini EOB packet md.end_of_burst   = true; 
tx_stream->send("", 0, md);___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Phase compensate issue

2017-11-12 Thread Hojoon Yang via USRP-users

Hi guys!please let me know whether following operation is possible!we have USRP 
B200.All I want to do is to transmit a specific signal without distorting 
phase.Say, I want to transmit the cosine wave, which have center frequency fc = 
3Mhz and phase is 60 degree(i.e. y = cos(2*pi*3e6*t + pi/3) ) through the Tx/Rx 
channel in USRP B200.But, I heard that there is a consistent phase offset after 
tuning. Thus, when we transmit the cosine signal as it is, it will have phase 
offset. I dont care the amplitude, but only care the exact phase.In order to 
compensate the phase offset, we are going to receive the signal which is 
transmitted from the Tx/Rx channel since we don't know the phase offset before 
it transmits. If we receive the signal, then we can know the phase offset 
'theta'. since we know the phase offset theta, to compensate the phase offset, 
We multiply that signal by -theta.In summary,(a) USRP B210 transmit the signal 
through the Tx/Rx channel, which will have phase offset, say X.(b) the usrp 
receive the (a) signal to know the phase offset X through RX2 channel(i.e. A 
loopback using a single USRP.)(c) multiply the signal samples by -X  to 
compensate the phase and transmit!1. Will it be possible??2. Marcus said that 
The SBX has a special architecture based on a LO synthesizer that allows to 
have a deterministic phase after "tuning"What is the exact meaning of tuning? 
it means frequency lock?___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Receive samples at exact time_spec_t

2017-11-16 Thread Hojoon Yang via USRP-users

Hi.I use USRP B200 with external on-board GPSDO.1. I set the clock source and 
time soure to GPSDOusrp->set_clock_source("gpsdo", 0);
usrp->set_time_source("gpsdo", 0);2. Set_time_next_pps and sleep 2 secs.
usrp->set_time_next_pps(uhd::time_spec_t(0.0), 0);
boost::this_thread::sleep(boost::posix_time::seconds(2));3. Issue the stream 
command to start the stream from 3.0 seconds.uhd::stream_cmd_t 
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
stream_cmd.num_samps = 100;stream_cmd.stream_now = false;const 
uhd::time_spec_t stream_time = uhd::time_spec_t(3.0);stream_cmd.time_spec = 
stream_time;rx_stream->issue_stream_cmd(stream_cmd);4. Start the Rx streams 
and check received time.size_t num_rx_samps = 
rx_stream->recv(&buff.front(), buff.size(), md, 5.0);    
---
Received packet: 100 samples, 3 full secs, 0.37 frac secs Stream 
time was: 3 full secs, 0.00 frac secs Difference between stream time 
and first packet: 37.093750 usI command to start receving from 3.0 seconds, but 
the USRP B200 does not start at exact time(there are some delay, 37us).I guess 
it seems normal.(a)But is there any method to overcome this tiny difference? at 
least below 10 us.(b)Is the difference always same? If not, Could you tell me 
which things could change the difference? (c)Can I solve the problem If I set 
the stream time to 3.0s - 37us?It will be very appreciated if someone could 
answer the above three questions!Thanks in advance.___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Test failed when executing test_messages.cpp

2017-11-16 Thread Hojoon Yang via USRP-users

Hi all.When I executed the uhd example(test_messages.cpp) using USRP B200, lots 
of test failed.I want to know whether following results are normal or not.I 
executed each of the following three commands twice.1. sudo 
./test_messagesSummary:Test Burst ACK-> 8 successes,   4 failuresTest 
Underflow-> 2 successes,   4 failuresTest Time Error   -> 0 
successes,  13 failuresTest Late Command   ->19 successes,   0 
failuresDone!Summary:Test Burst ACK-> 7 successes,   3 failuresTest 
Underflow-> 5 successes,  10 failuresTest Time Error   -> 0 
successes,  11 failuresTest Late Command   ->14 successes,   0 
failuresDone!*once moreSummary:Test Burst ACK-> 6 successes,   3 
failuresTest Underflow-> 4 successes,   8 failuresTest Time Error   ->  
   0 successes,  15 failuresTest Late Command   ->14 successes,   0 
failuresDone!2. sudo ./test_messages --ntests 100Summary:Test Burst ACK->   
 16 successes,   7 failuresTest Underflow-> 8 successes,  12 
failuresTest Time Error   -> 0 successes,  37 failuresTest Late Command   
->20 successes,   0 failuresDone!Summary:Test Burst ACK->27 
successes,   6 failuresTest Underflow->14 successes,  11 failuresTest 
Time Error   -> 0 successes,  19 failuresTest Late Command   ->23 
successes,   0 failuresDone!3. sudo ./test_messages --test-chainSummary:Test 
Burst ACK->12 successes,   3 failuresTest Underflow-> 6 
successes,   3 failuresTest Time Error   -> 0 successes,   8 failuresTest 
Late Command   -> 9 successes,   0 failuresTest Broken Chain   -> 0 
successes,   9 failuresDone!Summary:Test Burst ACK-> 8 successes,   6 
failuresTest Underflow-> 6 successes,   3 failuresTest Time Error   ->  
   0 successes,  10 failuresTest Late Command   ->13 successes,   0 
failuresTest Broken Chain   -> 0 successes,   4 failuresDone!___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] the time actually transmitted

2017-11-17 Thread Hojoon Yang via USRP-users

Hi all.In rx_medata_t, there is a time_spec which displays the time when a 
first sample is received.Thus, we can see the timing difference between the 
time "actually" transmitted and the time we "command".For example, I command 
"issue_stream_command" to start receiving at time t0, but I noticed that the 
actual reception start time was t0+delta by observing the time_spec in 
rx_metadata_t.My question:When we transmit the samples, is there any similar 
metadata or something that shows the "actual" transmited time of the first 
sample?I know that we can set the time when to transmit the samples, but I want 
to know the actual transmitted time.___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] transmission at specific time t0.

2017-11-17 Thread Hojoon Yang via USRP-users

Hi all.I'm still trying to know that when we command to transmit the samples at 
specific time t0, its actual transmitted time is exact time t0?because, in Rx, 
it does not receive exact time t0. there are some delays between them(about 
30us depending on the master clock rate or sampling rate, thanks to Dario 
Fetonani).If there is a delay when Tx, How can we measure the difference?It 
will be very appreciated if someone answer the question.Thanks.::Original 
message::Hi all.In rx_medata_t, there is a time_spec which displays the time 
when a first sample is received.Thus, we can see the timing difference between 
the time "actually" transmitted and the time we "command".For example, I 
command "issue_stream_command" to start receiving at time t0, but I noticed 
that the actual reception start time was t0+delta by observing the time_spec in 
rx_metadata_t.My question:When we transmit the samples, is there any similar 
metadata or something that shows the "actual" transmited time of the first 
sample?I know that we can set the time when to transmit the samples, but I want 
to know the actual transmitted time.___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] GPS antenna with power splitter

2017-11-27 Thread Hojoon Yang via USRP-users

Hi.I have two USRP B200 and each USRP is equipped with GPSDO. Also, I have one 
5v active GPS antenna, and one power divider(1 input and 2 outputs) whose 
operation frequency is 0.7~2.7GHz.In power divider, the input port is connected 
to the GPS antenna and each output port is connected to a different GPS ANT 
port on the USRP B200.I want two USRP B200 to receive GPS signal from only one 
antenna. That's why I use power divider.So, I wonder this configuration works 
well compared to two GPS antenna configuration (i.e. each USRP are connected to 
their own GPS antenna).Is there "any" dis-advantage compared to two antenna 
config?I tested it and observed that both USRP's GPS ANT LED was "green" and 
seems to work but not sure. I executed the sync_to_gps program for both USRP 
and it worked well.Thanks.Regards,___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] GPS antenna with power splitter

2017-11-27 Thread Hojoon Yang via USRP-users

Thank you for reply, hossein.Regards,
---원본메일---보낸사람 : hossein talaiee 
받는사람: Hojoon Yang 참 조: 
usrp-users@lists.ettus.com보낸날짜: 2017-11-27 23:40:31 GMT +0900 (ROK)제목: Re: 
[USRP-users] GPS antenna with power splitter
 
 
  
   
There is no difference but at least 3dB loss for GPS signal that has no 
noticeable adverse effect on GPSDO performance

   
  
  
   
   
On Mon, Nov 27, 2017 at 5:13 PM, Hojoon Yang via USRP-users 
 wrote:


 Hi.
 
 I have two USRP B200 and each USRP is equipped with GPSDO. Also, I have 
one 5v active GPS antenna, and one power divider(1 input and 2 outputs) whose 
operation frequency is 0.7~2.7GHz.
 
 In power divider, the input port is connected to the GPS antenna and each 
output port is connected to a different GPS ANT port on the USRP B200.
 
 I want two USRP B200 to receive GPS signal from only one antenna. That's 
why I use power divider.
 
 So, I wonder this configuration works well compared to two GPS antenna 
configuration (i.e. each USRP are connected to their own GPS antenna).
 
 Is there "any" dis-advantage compared to two antenna config?
 
 I tested it and observed that both USRP's GPS ANT LED was "green" and 
seems to work but not sure. I executed the sync_to_gps program for both USRP 
and it worked well.
 
 Thanks.
 
 Regards, 
 
 __
 _
  USRP-users mailing list
  
 USRP-users@lists.ettus.com
  
 http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
  
 

   
   
   
 
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Test_messages example

2017-11-30 Thread Hojoon Yang via USRP-users

Hi all.Could someone share the execution results of "test_messages" example? 
Because there are several test failures in my result.I use USRP B200 with 
GPSDO.My result is as follows. Is it normal 
result?--Summary:Test Burst ACK->14 successes,  
 2 failuresTest Underflow-> 9 successes,   4 failuresTest Time Error   
-> 0 successes,   8 failuresTest Late Command   ->13 successes,   0 
failuresDone!--Regards,___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] A random phase offset

2018-03-07 Thread Hojoon Yang via USRP-users

Hi, folks.In application note from Ettus, "Synchronization and MIMO Capability 
with USRP Devices",They said that "Generally, these fractional-N
synthesizers introduce a random phase offset after each retune."What does 
"random phase offset" mean?Q1. Does it mean that if I send a signal, 
Acos(fc*t), then It actually sends the signal Acos(fc*t + "random phase")?Q2. 
After retuning, unless I retune it again, does the random phase offset retain 
consistently?Am I correct?Thanks in advance.Regards,___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] UBX vs SBX

2018-03-13 Thread Hojoon Yang via USRP-users

Hi.I have two USRP X310s and wonder which board between SBX and UBX would be 
the suitable for me.I'm gonna buy four daughterboards to use it as 2x2 MIMO. 
One USRP X310 for Tx, the other USRP for Rx.My target frequency is from 1.8GHz 
to 2.8GHz. According to datasheet, Both UBX and SBX work on the target 
frequency.I saw the schematic of both SBX and UBX and figured it out that UBX 
has a significantly different structure from SBX.I wonder, which board performs 
better "in the target frequency" in terms of MIMO performance(i.e. phase align 
accuracy, noise level, etc..).I don't have price issue. If the UBX performs 
better or same as the SBX in target frequency(1.8GHz~2.8GHz), I would like to 
buy UBX since it has more wide frequency range.Regards,___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Align LOs in the front-end for Tx

2018-03-15 Thread Hojoon Yang via USRP-users

Hi all.Let's say we have one USRP X310 and two UBX-160 daughterboards.According 
to the page_sync manual(i.e. https://files.ettus.com/manual/page_sync.html), 
there is a code snippet for aligning LOs.Do I need to execute the same thing 
for Tx? Because the code only describes for Rx case.Regards,___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Octoclock reference unlock

2018-04-24 Thread Hojoon Yang via USRP-users

Hi.I got an octoclock-G (GPSDO included) yesterday.I connected the octoclock 
(without external antenna) to usrp b210 properly.However, when I executed the 
usrp_list_sensors.cpp or test_clock_synch.cpp which are included in 
examples,sometimes I got that Reference is not locked, sometimes I got ref is 
locked.Why is this so unstable? is this a normal behavior?If I use GPS antenna, 
the reference lock status would be stable as "locked"?Hojoon.___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Octoclock reference unlock

2018-04-24 Thread Hojoon Yang via USRP-users

e:     type: octoclockHojoon
---Original Message---From: "Marcus D. 
Leech via USRP-users" To: 
usrp-users@lists.ettus.comSent date: 2018-04-25 02:51:18 GMT +0900 
(ROK)Subject: Re: [USRP-users] Octoclock reference unlock
  
   
  
  
  
   On 04/24/2018 11:34 AM, Hojoon Yang via USRP-users wrote:

   
   
   Hi. 

   I got an octoclock-G (GPSDO included) yesterday. 

   I connected the octoclock (without external antenna) to usrp b210 properly. 

   However, when I executed the usrp_list_sensors.cpp or test_clock_synch.cpp 
which are included in examples, 

   sometimes I got that Reference is not locked, sometimes I got ref is locked. 

   Why is this so unstable? is this a normal behavior?  

   If I use GPS antenna, the reference lock status would be stable as "locked"? 

   Hojoon.  
   
   Could you share the exact arguments you used with these two applications?
   
   What version of UHD are you using?
   
   
   
 
 
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Octoclock reference unlock

2018-04-24 Thread Hojoon Yang via USRP-users

Thank you for reply, Marcus.I replaced the USRP B200 with internal GPSDO to 
USRP B210 without internal GPSDO.However, I got same result. when I typed "sudo 
./usrp_list_sensors", sometimes Ref: locked, sometimes Ref: unlocked..I waited 
about 10 minute, before I executed the application. I thought It needs time to 
be locked.Following are the outputs.--OUTPUT 
1-[INFO] [UHD] linux; GNU C++ version 4.8.4; 
Boost_105400; UHD_3.11.0.1-0-ge00f1f37[INFO] [B200] Detected Device: B210[INFO] 
[B200] Operating over USB 3.[INFO] [B200] Initialize CODEC control...[INFO] 
[B200] Initialize Radio control...[INFO] [B200] Performing register loopback 
test... [INFO] [B200] Register loopback test passed[INFO] [B200] Performing 
register loopback test... [INFO] [B200] Register loopback test passed[INFO] 
[AD936X] Performing CODEC loopback test... [INFO] [AD936X] CODEC loopback test 
passed[INFO] [AD936X] Performing CODEC loopback test... [INFO] [AD936X] CODEC 
loopback test passed[INFO] [B200] Setting master clock rate selection to 
'automatic'.[INFO] [B200] Asking for clock rate 16.00 MHz... [INFO] [B200] 
Actually got clock rate 16.00 MHz.Device contains 1 motherboard(s).  
_ /|   Sensors for 
motherboard 0: |   |   * Ref: unlocked| 
_|    /|   |   RX 
Sensors: |   |   |   |   Chan 0: |   |   * temp: 39.298248 C|   |   * RSSI: 
-50.75 dB|   |   * LO: locked|   |   |   |   Chan 1: |   |   * temp: 
39.883041 C|   |   * RSSI: -50.75 dB|   |   * LO: locked|   | 
_|    /|   |   TX 
Sensors: |   |   |   |   Chan 0: |   |   * temp: 40.175438 C|   |   * LO: 
locked|   |   |   |   Chan 1: |   |   * temp: 40.175438 C|   |   * LO: 
locked- OUTPUT 
2[INFO] [UHD] linux; GNU C++ 
version 4.8.4; Boost_105400; UHD_3.11.0.1-0-ge00f1f37[INFO] [B200] Detected 
Device: B210[INFO] [B200] Operating over USB 3.[INFO] [B200] Initialize CODEC 
control...[INFO] [B200] Initialize Radio control...[INFO] [B200] Performing 
register loopback test... [INFO] [B200] Register loopback test passed[INFO] 
[B200] Performing register loopback test... [INFO] [B200] Register loopback 
test passed[INFO] [AD936X] Performing CODEC loopback test... [INFO] [AD936X] 
CODEC loopback test passed[INFO] [AD936X] Performing CODEC loopback test... 
[INFO] [AD936X] CODEC loopback test passed[INFO] [B200] Setting master clock 
rate selection to 'automatic'.[INFO] [B200] Asking for clock rate 16.00 
MHz... [INFO] [B200] Actually got clock rate 16.00 MHz.Device contains 1 
motherboard(s).  _ /|   
Sensors for motherboard 0: |   |   * Ref: locked| 
_|    /|   |   RX 
Sensors: |   |   |   |   Chan 0: |   |   * temp: 39.298248 C|   |   * RSSI: 
-50.75 dB|   |   * LO: locked|   |   |   |   Chan 1: |   |   * temp: 
39.883041 C|   |   * RSSI: -50.75 dB|   |   * LO: locked|   | 
_|    /|   |   TX 
Sensors: |   |   |   |   Chan 0: |   |   * temp: 40.175438 C|   |   * LO: 
locked|   |   |   |   Chan 1: |   |   * temp: 40.175438 C|   |   * LO: 
lockedHojoon
---Original Message---From: "Marcus D. 
Leech via USRP-users" To: 
usrp-users@lists.ettus.comSent date: 2018-04-25 11:41:08 GMT +0900 
(ROK)Subject: Re: [USRP-users] Octoclock reference unlock
 
 
  On 04/24/2018 10:34 PM, Hojoon Yang via USRP-users wrote: 
   > 
   > Hi, Marcus. 
   > 
   > 1. usrp_list_sensors 
   > 
   > I didn't give any aruguments, I just typed "sudo ./usrp_list_sensors" 
   > 
   > ---OUTPUT 1- 
   > 
   > Device contains 1 motherboard(s). 
   > 
   > _ 
   > / 
   > | Sensors for motherboard 0: 
   > | 
   > | * GPS_GPGGA: 
   > $GPGGA,140136.00,.,N,0.,E,0,99,1.0,0.0,M,0.0,M,,*5D 
   > | * GPS_GPRMC: 
   > $GPRMC,140136.00,V,.,N,0.,E,0.0,0.0,010106,,*23 
   > | * GPS epoch time: 1136124097 seconds 
   > | * GPS lock status: unlocked 
   > | * GPS_SERVO: 06-01-01 0 39517 0.00 1.00E-08 0 0 1 0x38 
   > | * Ref: locked 
   > | _ 
   > | / 
   > | | RX Sensors: 
   > | | 
   > | | Chan 0: 
   > | | * temp: 47.485382 C 
   > | | * RSSI: -50.75 dB 
   > | | * LO: locked 
   > | 
   > | _ 
   > | / 
   > | | TX Sensors: 
   > | | 
   > | | Chan 0:

Re: [USRP-users] Octoclock reference unlock

2018-04-25 Thread Hojoon Yang via USRP-users

When I executed the sync_to_gps, it always outputs "ref locked".However, if I 
executed usrp_list_sensors and test_clock_synch, the reference lock status is 
quite unstable.I guess I found the reason why it is unstable.this is because 
the "unstable" applications check the "ref_locked" sensors only one 
time.However, in sync_to_gps, there is a loop to check the sensor "ref_locked" 
many times.So, the one who wants to check the reference lock status precisely 
should check the sensor more than 3~4 times. Not only one time.Hojoon
---원본메일---보낸사람 : "Marcus D. Leech via 
USRP-users" 받는사람: usrp-users@lists.ettus.com보낸날짜: 
2018-04-25 22:02:35 GMT +0900 (ROK)제목: Re: [USRP-users] Octoclock reference 
unlock
 
 
  On 04/24/2018 11:24 PM, Hojoon Yang via USRP-users wrote: 
   > 
   > Thank you for reply, Marcus. 
   > 
   > I replaced the USRP B200 with internal GPSDO to USRP B210 without 
   > internal GPSDO. 
   > 
   > However, I got same result. 
   > 
   > when I typed "sudo ./usrp_list_sensors", sometimes Ref: locked, 
   > sometimes Ref: unlocked.. 
   > 
   > I waited about 10 minute, before I executed the application. I thought 
   > It needs time to be locked. 
   > 
   > Following are the outputs. 
   > 
   > 
   Could you try a different 10MHz port on your Octoclock? Could you try a 
   different cable? 
   
   
   
   ___ 
   USRP-users mailing list 
   USRP-users@lists.ettus.com 
   
  http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com 
   
   
 
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] synchronization between two usrps.

2018-04-25 Thread Hojoon Yang via USRP-users

Hi,I connected one usrp b210 and one usrp b200 to octoclock for 
synchronization.I'm trying to verify that the usrps connected to octoclock is 
"really" synchronized.To check it, I did as 
follows.usrp->set_time_next_pps(uhd::time_spec_t(0.0));usrp2->set_time_next_pps(uhd::time_spec_t(0.0));boost::this_thread::sleep(boost::posix_time::seconds(2));uhd::time_spec_t
 start_time = usrp->get_time_now() + 
uhd::time_spec_t(0.1);usrp->set_command_time(start_time);uhd::time_spec_t 
usrp_t = usrp->get_time_now();uhd::time_spec_t usrp2_t = 
usrp2->get_time_now();usrp->clear_command_time();I think I did wrong, because 
the results are different from my expectations.Q1. Can I execute 
usrp->get_time_now(); and usrp2->get_time_now(); simultaneously? I'm trying to 
use set_command_time, but it didn't work well as above.Q2. How can I verify 
that the two usrps connected to the octoclock, is really synchronized? in terms 
of time..I already used get_time_last_pps() command, this command works 
perfect, the two usrps showed same value.but this command only showed "the 
full_secs" which does not include frac_secs.. I want to check "the frac_secs" 
between two usrps.I read this thread, 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-January/012227.htmlBut,
 I can't find the way to check frac_secs..Hojoon___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] synchronization between two usrps.

2018-04-25 Thread Hojoon Yang via USRP-users

The questions were not about time_spec_t and get_real_secs()..I wondered that 
"How can I execute the command usrp->get_time_now(); and usrp2->get_time_now(); 
simultaneously.As I mentioned the previous question, I tried to use 
set_command_time(), but it does not work.the code that I tried 
is---usrp->set_time_next_pps(uhd::time_spec_t(0.0));
usrp2->set_time_next_pps(uhd::time_spec_t(0.0));
boost::this_thread::sleep(boost::posix_time::seconds(2));uhd::time_spec_t 
start_time = usrp->get_time_now() + uhd::time_spec_t(0.3);
usrp->set_command_time(start_time);uhd::time_spec_t usrp_t = 
usrp->get_time_now();uhd::time_spec_t usrp2_t = usrp2->get_time_now();
usrp->clear_command_time();std::cout << boost::format(" Start   
: %f us\n"" Response 1: %f us\n"" Response 2: %f 
us") % (start_time.get_real_secs()*1e6) % (usrp_t.get_real_secs()*1e6) 
% (usrp2_t.get_real_secs()*1e6) << std::endl;std::cout << boost::format(
" Difference of response time 1: %f us") % ((usrp_t - 
start_time).get_real_secs()*1e6) << std::endl;std::cout << boost::format(   
 " Difference of response time 2: %f us") % ((usrp2_t - 
start_time).get_real_secs()*1e6) << 
std::endl;---OUTPUT-Checking
 USRP devices for lock.Waiting for reference lock * 30FDE72: LOCKEDWaiting 
for reference lock... * 3125CB5: LOCKEDQuerying Clock for time and setting USRP 
times... Start   : 1329026.312500 us Response 1: 1329026.625000 us Response 
2: 1329261.625000 us Difference of response time 1: 0.312500 us Difference of 
response time 2: 235.312500 
us-What I 
expect was, in OUTPUT, Difference of response time 2 should be 0.312500 us, not 
235.312500 us.This result means that the command usrp->get_time_now(); and 
usrp2->get_time_now(); were not executed simultaneously.I also changed the 
code-uhd::time_spec_t
 start_time = usrp->get_time_now() + 
uhd::time_spec_t(0.3);usrp->set_command_time(start_time);uhd::time_spec_t 
usrp_t = usrp->get_time_now();uhd::time_spec_t usrp2_t = 
usrp2->get_time_now();usrp->clear_command_time();-to-uhd::time_spec_t
 start_time = usrp->get_time_now() + 
uhd::time_spec_t(0.3);usrp->set_command_time(start_time);usrp2->set_command_time(start_time);uhd::time_spec_t
 usrp_t = usrp->get_time_now();uhd::time_spec_t usrp2_t = 
usrp2->get_time_now();usrp->clear_command_time();usrp2->clear_command_time();-But
 it does not work.Again, How can I execute the command usrp->get_time_now(); 
and usrp2->get_time_now(); simultaneously?usrp: USRP B210usrp2: USRP B200Hojoon
---원본메일---보낸사람 : "Marcus D. Leech via 
USRP-users" 받는사람: usrp-users@lists.ettus.com보낸날짜: 
2018-04-26 01:41:04 GMT +0900 (Asia/Seoul)제목: Re: [USRP-users] synchronization 
between two usrps.
  
   
  
  
  
   On 04/25/2018 10:53 AM, Hojoon Yang via USRP-users wrote:

   
   
   Hi, 

   I connected one usrp b210 and one usrp b200 to octoclock for 
synchronization. 

   I'm trying to verify that the usrps connected to octoclock is "really" 
synchronized. 

   To check it, I did as follows. 

   usrp->set_time_next_pps(uhd::time_spec_t(0.0)); 
   usrp2->set_time_next_pps(uhd::time_spec_t(0.0)); 
   boost::this_thread::sleep(boost::posix_time::seconds(2)); 

   uhd::time_spec_t start_time = usrp->get_time_now() + uhd::time_spec_t(0.1); 
   usrp->set_command_time(start_time); 
   uhd::time_spec_t usrp_t = usrp->get_time_now(); 
   uhd::time_spec_t usrp2_t = usrp2->get_time_now(); 
   usrp->clear_command_time(); 

   I think I did wrong, because the results are different from my expectations. 

   Q1. Can I execute usrp->get_time_now(); and usrp2->get_time_now(); 
simultaneously? I'm trying to use set_command_time, but it didn't work well as 
above. 

   Q2. How can I verify that the two usrps connected to the octoclock, is 
really synchronized? in terms of time.. 

   I already used get_time_last_pps() command, this command works perfect, the 
two usrps showed same value. 

   but this command only showed "the full_secs" which does not include 
frac_secs.. I want to check "the frac_secs" between two usrps. 

   I read this threa

[USRP-users] What is wrong?

2018-04-29 Thread Hojoon Yang via USRP-users

Hi,For synchronization, manual(i.e. 
https://files.ettus.com/manual/page_sync.html) said md.start_of_burst = 
false.However, in tx_timed_samples.cpp, md.start_of_burst = true.Both manual 
and tx_timed_samples.cpp are latest version.which uage is right?-hojoon___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] What is wrong?

2018-04-29 Thread Hojoon Yang via USRP-users

Ah, sorry. there are some typos.manual : start_of_burst = true.exapmle : 
start_of_burst = false.Sorry about that.-hojoon
---원본메일---보낸사람 : Hojoon Yangvia 
USRP-users 받는사람: usrp-users@lists.ettus.com보낸날짜: 
2018-04-30 11:34:48 GMT +0900 (ROK)제목: [USRP-users]What is wrong?
 
 
  Hi,
  
  For synchronization, manual(i.e. 
https://files.ettus.com/manual/page_sync.html) said md.start_of_burst = false.
  
  However, in tx_timed_samples.cpp, md.start_of_burst = true.
  
  Both manual and tx_timed_samples.cpp are latest version.
  
  which uage is right?
  
  -hojoon 
  
 
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] X310 frequency accuracy spec

2018-05-01 Thread Hojoon Yang via USRP-users

Hi, all.In manual, I see the following sentece."The GPSDO improves the accuracy 
of the internal frequency reference to 20 ppb, or 0.1 ppb if the GPS is 
synchronized to the GPS constellation."[1]It said 0.1 ppb if the GPS 
synchronized. However, in the below table, Frequency Accuracy is 
+-0.01ppb.Question: 0.1 ppb vs 0.01 ppb. what is 
right?[1]https://kb.ettus.com/X300/X310___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X310 frequency accuracy spec

2018-05-01 Thread Hojoon Yang via USRP-users

Thank you Marcus. So, +-0.01ppb is right.If two USRP x310(both of them use 
OCXO) are communicating each other via coaxial cable at the frequency 1GHz, the 
receiver usrp x310 have to get the center frequency from (1GHz - 0.02Hz) to 
(1GHz + 0.02Hz). I mean, the frequency offset should be within 
+-0.02ppb.Because the maximum frequency offset between two USRP X310 would be 
-0.02ppb ~ +0.02ppb.Am I right?
---Original Message---From: "Marcus D. 
Leech via USRP-users" To: 
usrp-users@lists.ettus.comSent date: 2018-05-02 13:54:46 GMT +0900 
(ROK)Subject: Re: [USRP-users] X310 frequency accuracy spec
  
   
  
  
  
   On 05/02/2018 12:32 AM, Hojoon Yang via USRP-users wrote:

   
   
   Hi, all. 
 
   In manual, I see the following sentece. 
   "The GPSDO improves the accuracy of the internal frequency reference to 20 
ppb, or 0.1 ppb if the GPS is synchronized to the GPS constellation."[1] 
 
   It said 0.1 ppb if the GPS synchronized. However, in the below table, 
Frequency Accuracy is +-0.01ppb. 
 
   Question: 0.1 ppb vs 0.01 ppb. what is right? 
 
   [1]https://kb.ettus.com/X300/X310 
   

   Not sure precisely where those numbers come from.
   
   The Allan Deviation for a typical OCXO-based GPSDO is somewhere in the 
ballpark of 1.0e-11, at approximately 1000s integration time.
   
   Whether at any given moment, you're getting 1.0e-10 or 1.0e-11 isn't going 
to make much difference for the overwhelming majority
     of applications.
   
   Most telecom type applications have built-in frequency-offset compensation 
algorithms in the receiver code to cope with offsets well
     into the 1PPM or worse, range.  Some applications, like TDMA with tight 
timing, may require better, which is why external-clocking
     options are offered.
   
   
 
 
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] received signal fluctuation

2018-05-07 Thread Hojoon Yang via USRP-users

Hi,I transmitted 0.3 + 0.3i signals on the 900e6 frequency(i.e. sudo 
./tx_waveforms --rate 1e6 --freq 900e6 --ref "external" --gain 85)and then I 
received the signal(i.e. sudo ./rx_samples_to_file --type "float" --rate 1e6 
--freq 900e6 --gain 40 --nsamps 1)and then I extracted the real and 
imaginary parts using MATLAB and plotted it.I expected a constant line(i.e. 
0.3*gain on real, 0.3*gain on imag) on both real and imaginary figures since I 
transmitted a constant real and imaginary signal, but the figures were beyond 
my expectation. I attached the figures.Q1. Is it normal behavior?Q2. If it 
does, what's the source of this fluctuation?Here are my experimental 
setup.-Experimental setup:USRP B200 TX/RX <---> 30dB attenuator  
USRP B200 RX2Ref port on both USRP b200 are connected to the Octoclock-G. The 
octoclock-G use external antenna.the UHD version is 
"UHD_3.11.0.1-16-g34fc6362"Regards,Hojoon

real.png
Description: Binary data


imag.png
Description: Binary data
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] UHD installation

2018-05-07 Thread Hojoon Yang via USRP-users

Hi,When I executed the "uhd_find_devices"I got "[ERROR] [USB] USB open failed: 
insufficient permissions."However, when I put sudo in it(i.e. sudo 
uhd_find_devices", there is no such error.Also, when I typed "./tx_waveforms 
..."I got an following WARNING"[WARNING] [UHD] Unable to set the thread 
priority. Performance may be negatively affected.Please see the general 
application notes in the manual for instructions.EnvironmentError: OSError: 
error in pthread_setschedparam"similarly, the warning disappeared when I put 
the sudo in it.Marcus said it is incomplete installation, if the sudo needed.As 
Marcus recommended, I created(because there was no such file) 
/etc/udev/rules.d/10-usrp.rules and put the following contents.## Copyright 
2011,2015 Ettus Research LLC## This program is free software: you can 
redistribute it and/or modify# it under the terms of the GNU General Public 
License as published by# the Free Software Foundation, either version 3 of the 
License, or# (at your option) any later version.## This program is distributed 
in the hope that it will be useful,# but WITHOUT ANY WARRANTY; without even the 
implied warranty of# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See 
the# GNU General Public License for more details.## You should have received a 
copy of the GNU General Public License# along with this program.  If not, see 
.##USRP1SUBSYSTEMS=="usb", 
ATTRS{idVendor}=="fffe", ATTRS{idProduct}=="0002", 
MODE:="0666"#B100SUBSYSTEMS=="usb", ATTRS{idVendor}=="2500", 
ATTRS{idProduct}=="0002", MODE:="0666"#B200SUBSYSTEMS=="usb", 
ATTRS{idVendor}=="2500", ATTRS{idProduct}=="0020", 
MODE:="0666"SUBSYSTEMS=="usb", ATTRS{idVendor}=="2500", 
ATTRS{idProduct}=="0022", MODE:="0666"SUBSYSTEMS=="usb", 
ATTRS{idVendor}=="3923", ATTRS{idProduct}=="7813", 
MODE:="0666"SUBSYSTEMS=="usb", ATTRS{idVendor}=="3923", 
ATTRS{idProduct}=="7814", MODE:="0666"However, nothing changed.Do I need to 
re-install the uhd?Regards,Hojoon___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] UHD installation

2018-05-07 Thread Hojoon Yang via USRP-users

Thanks Marcus.I did it. But, nothing changed. I will re-install the uhd and 
come back if still have problems.But, is there any relationship between kernel 
version and uhd version? I use UHD 3.11.currently, I use Ubuntu 14.04.5 LTS and 
the kernel version is 4.2.0-42-genericBecause, the latest kernel version NI RIO 
supports is 4.2.x. I need it for USRP X310.Regards,Hojoon
---Original Message---From: "Marcus D. 
Leech via USRP-users" To: 
usrp-users@lists.ettus.comSent date: 2018-05-08 10:47:47 GMT +0900 
(Asia/Seoul)Subject: Re: [USRP-users] UHD installation
  
   
  
  
  
   On 05/07/2018 09:42 PM, Hojoon Yang via USRP-users wrote:

   
   
   Hi, 

   When I executed the "uhd_find_devices" 

   I got "[ERROR] [USB] USB open failed: insufficient permissions." 
 
   However, when I put sudo in it(i.e. sudo uhd_find_devices", there is no such 
error. 

   Also, when I typed "./tx_waveforms ..." 

   I got an following WARNING 
   "[WARNING] [UHD] Unable to set the thread priority. Performance may be 
negatively affected. 
   Please see the general application notes in the manual for instructions. 
   EnvironmentError: OSError: error in pthread_setschedparam" 

   similarly, the warning disappeared when I put the sudo in it. 

   Marcus said it is incomplete installation, if the sudo needed. 

   As Marcus recommended, I created(because there was no such file) 
/etc/udev/rules.d/10-usrp.rules and put the following contents. 

   # # Copyright 2011,2015 Ettus Research LLC # # This program is free 
software: you can redistribute it and/or modify # it under the terms of the GNU 
General Public License as published by # the Free Software Foundation, either 
version 3 of the License, or # (at your option) any later version. # # This 
program is distributed in the hope that it will be useful, # but WITHOUT ANY 
WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR 
A PARTICULAR PURPOSE.  See the # GNU General Public License for more details. # 
# You should have received a copy of the GNU General Public License # along 
with this program.  If not, see <http://www.gnu.org/licenses/>. #  #USRP1 
SUBSYSTEMS=="usb", ATTRS{idVendor}=="fffe", ATTRS{idProduct}=="0002", 
MODE:="0666"  #B100 SUBSYSTEMS=="usb", ATTRS{idVendor}=="2500", 
ATTRS{idProduct}=="0002", MODE:="0666"  #B200 SUBSYSTEMS=="usb", 
ATTRS{idVendor}=="2500", ATTRS{idProduct}=="0020", MODE:="0666" 
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2500", ATTRS{idProduct}=="0022", 
MODE:="0666" SUBSYSTEMS=="usb", ATTRS{idVendor}=="3923", 
ATTRS{idProduct}=="7813", MODE:="0666" SUBSYSTEMS=="usb", 
ATTRS{idVendor}=="3923", ATTRS{idProduct}=="7814", MODE:="0666" 
 
 
   However, nothing changed. 
 
   Do I need to re-install the uhd? 


   Regards, 
   Hojoon 
   

   You also need to:
   
   sudo udevadm control --reload-rules
   
   And then  replug your USRP
   
   
 
 
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] UHD installation

2018-05-07 Thread Hojoon Yang via USRP-users

Hi, I resolved the "[ERROR] [USB] USB open failed: insufficient permissions." 
problemby the following commands,sudo cp uhd-usrp.rules /etc/udev/rules.d/sudo 
udevadm control --reload-rulessudo udevadm triggerHowever, I still get the 
warning if I executed the uhd example programs without "sudo"[WARNING] [UHD] 
Unable to set the thread priority. Performance may be negatively 
affected.Please see the general application notes in the manual for 
instructions.EnvironmentError: OSError: error in pthread_setschedparamFor 
example,sudo ./tx_waveforms .. -> No such warning./tx_waveforms .. -> [WARNING] 
[UHD ].Is this a bug? or normal behavior?Regards,Hojoon
---Original Message---From: Hojoon 
Yangvia USRP-users To: "Marcus D. Leech via 
USRP-users" Sent date: 2018-05-08 11:33:40 GMT 
+0900 (Asia/Seoul)Subject: Re: [USRP-users]UHD installation
 
 
  Thanks Marcus.
  
  I did it. But, nothing changed. I will re-install the uhd and come back if 
still have problems.
  
  But, is there any relationship between kernel version and uhd version? I use 
UHD 3.11.
  
  currently, I use Ubuntu 14.04.5 LTS and the kernel version is 4.2.0-42-generic
  
  Because, the latest kernel version NI RIO supports is 4.2.x. I need it for 
USRP X310.
  
  Regards,
  
  Hojoon
  
  
   
---Original Message---
From: "Marcus D. Leech via USRP-users" 
To: usrp-users@lists.ettus.com
Sent date: 2018-05-08 10:47:47 GMT +0900 (Asia/Seoul)
Subject: Re: [USRP-users] UHD installation
    
    
   
     On 05/07/2018 09:42 PM, Hojoon Yang via USRP-users wrote: 
 


Hi, 
 
When I executed the "uhd_find_devices" 
 
I got "[ERROR] [USB] USB open failed: insufficient permissions." 
  
However, when I put sudo in it(i.e. sudo uhd_find_devices", there is no 
such error. 
 
Also, when I typed "./tx_waveforms ..." 
 
I got an following WARNING 
"[WARNING] [UHD] Unable to set the thread priority. Performance may be 
negatively affected. 
Please see the general application notes in the manual for instructions. 
EnvironmentError: OSError: error in pthread_setschedparam" 
 
similarly, the warning disappeared when I put the sudo in it. 
 
Marcus said it is incomplete installation, if the sudo needed. 
 
As Marcus recommended, I created(because there was no such file) 
/etc/udev/rules.d/10-usrp.rules and put the following contents. 
 
# # Copyright 2011,2015 Ettus Research LLC # # This program is free 
software: you can redistribute it and/or modify # it under the terms of the GNU 
General Public License as published by # the Free Software Foundation, either 
version 3 of the License, or # (at your option) any later version. # # This 
program is distributed in the hope that it will be useful, # but WITHOUT ANY 
WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR 
A PARTICULAR PURPOSE.  See the # GNU General Public License for more details. # 
# You should have received a copy of the GNU General Public License # along 
with this program.  If not, see <http://www.gnu.org/licenses/>. #  #USRP1 
SUBSYSTEMS=="usb", ATTRS{idVendor}=="fffe", ATTRS{idProduct}=="0002", 
MODE:="0666"  #B100 SUBSYSTEMS=="usb", ATTRS{idVendor}=="2500", 
ATTRS{idProduct}=="0002", MODE:="0666"  #B200 SUBSYSTEMS=="usb", 
ATTRS{idVendor}=="2500", ATTRS{idProduct}=="0020", MODE:="0666" 
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2500", ATTRS{idProduct}=="0022", 
MODE:="0666" SUBSYSTEMS=="usb", ATTRS{idVendor}=="3923", 
ATTRS{idProduct}=="7813", MODE:="0666" SUBSYSTEMS=="usb", 
ATTRS{idVendor}=="3923", ATTRS{idProduct}=="7814", MODE:="0666" 
  
  
However, nothing changed. 
  
Do I need to re-install the uhd? 
 
 
Regards, 
Hojoon 
 
 
You also need to: 

sudo udevadm control --reload-rules 

And then  replug your USRP 



   
  
 
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] timed stream in USRP X310 and B210

2018-05-25 Thread Hojoon Yang via USRP-users

Hi,I am currently using UHD 3.11.0.1 and I have two USRPs, B210 and X310.while 
executing the tx_timed_samples in the example, the behavior of the send() 
function was different between B210 and X310.More specifically,In B210, I do 
./tx_timed_samples --rate 1e6 --secs 8 --nsamps 100 --args name=MyB210The 
host does not send "whole samples" at the beginning, which means that the 
send() got stuck when the buffer in the USRP is full.When the times up, the 
USRP transmitted the samples and the send function push the samples to the USRP 
again.However, In X310, I did exact same command except the --args,but the 
results are quite different. the send() is flushing "all the samples" to the 
USRP at the beginning. I don't believe the USRP X310 has a huge buffer to 
handle the 1,000,000 samples.Anyway the result is failed in X310 case. i.e. I 
got "Waiting for async burst ACK... failed".But in B210 I got success flag.the 
X310 is connected to the host PC with 1G ethernet cable.What did I 
wrong?Regards,Hojoon___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] timed stream in USRP X310 and B210

2018-05-25 Thread Hojoon Yang via USRP-users

In addition, USRP X310 + 2 UBX-160 v2
---원본메일---보낸사람 : Hojoon Yang via 
USRP-users 받는사람: usrp-users@lists.ettus.com보낸날짜: 
2018-05-25 20:59:17 GMT +0900 (Asia/Seoul)제목: [USRP-users]timed stream in USRP 
X310 and B210
 
 
  Hi,
  
  I am currently using UHD 3.11.0.1 and I have two USRPs, B210 and X310.
  
  while executing the tx_timed_samples in the example, the behavior of the 
send() function was different between B210 and X310.
  
  More specifically,
  
  In B210, I do ./tx_timed_samples --rate 1e6 --secs 8 --nsamps 100 --args 
name=MyB210
  
  The host does not send "whole samples" at the beginning, which means that the 
send() got stuck when the buffer in the USRP is full.
  
  When the times up, the USRP transmitted the samples and the send function 
push the samples to the USRP again.
  
  However, In X310, I did exact same command except the --args,
  
  but the results are quite different. the send() is flushing "all the samples" 
to the USRP at the beginning. I don't believe the USRP X310 has a huge buffer 
to handle the 1,000,000 samples.
  
  Anyway the result is failed in X310 case. i.e. I got "Waiting for async burst 
ACK... failed".
  
  But in B210 I got success flag.
  
  the X310 is connected to the host PC with 1G ethernet cable.
  
  What did I wrong?
  
  Regards,
  
  Hojoon 
  
 
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] timed stream in USRP X310 and B210

2018-05-25 Thread Hojoon Yang via USRP-users

Hi, Thanks for reply.I tried it on UHD 3.11.1, because this version is the 
latest release version in github.But, the result has not changed. It still 
failed.
---Original Message---From: "Marcus D. 
Leech via USRP-users" To: 
usrp-users@lists.ettus.comSent date: 2018-05-25 23:12:28 GMT +0900 
(Asia/Seoul)Subject: Re: [USRP-users] timed stream in USRP X310 and B210
  
   
  
  
  
   On 05/25/2018 10:06 AM, Hojoon Yang via USRP-users wrote:

   
   
   In addition, USRP X310 + 2 UBX-160 v2 



 ---원본메일---
      보낸사람 : Hojoon Yang via USRP-users 
 
  받는사람: 
 usrp-users@lists.ettus.com
  보낸날짜: 2018-05-25 20:59:17 GMT +0900 (Asia/Seoul)
  제목: [USRP-users]timed stream in USRP X310 and B210
 
Hi, 
 
I am currently using UHD 3.11.0.1 and I have two USRPs, B210 and X310. 
 
while executing the tx_timed_samples in the example, the behavior of the 
send() function was different between B210 and X310. 
 
More specifically, 
 
In B210, I do ./tx_timed_samples --rate 1e6 --secs 8 --nsamps 100 
--args name=MyB210 
  
The host does not send "whole samples" at the beginning, which means that 
the send() got stuck when the buffer in the USRP is full. 
  
When the times up, the USRP transmitted the samples and the send function 
push the samples to the USRP again. 
 
However, In X310, I did exact same command except the --args, 
 
but the results are quite different. the send() is flushing "all the 
samples" to the USRP at the beginning. I don't believe the USRP X310 has a huge 
buffer to handle the 1,000,000 samples. 

   The USRP doesn't, but the operating system network stack does.   The buffer 
dynamics of USB vs the network interface are quite different.
   
   

  
Anyway the result is failed in X310 case. i.e. I got "Waiting for async 
burst ACK... failed". 

   Could you try reverting to a 3.10 UHD, or the latest (3.12) ?
   
   
   
   

  
But in B210 I got success flag. 
  
the X310 is connected to the host PC with 1G ethernet cable. 
  
What did I wrong? 
  
Regards, 
  
Hojoon 
 

   



   ___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
 
   
 
 
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] timed stream in USRP X310 and B210

2018-05-25 Thread Hojoon Yang via USRP-users

In X310, when I reduce the total number of samples from 1,000,000 to 100,000, 
it returns success.However, in the B210, it returns success even though the # 
of samples is 1,000,000.
---Original Message---From: Hojoon Yang 
via USRP-users To: "Marcus D. Leech via USRP-users" 
Sent date: 2018-05-25 23:51:31 GMT +0900 
(Asia/Seoul)Subject: Re: [USRP-users]timed stream in USRP X310 and B210
 
 
  Hi, Thanks for reply.
  
  I tried it on UHD 3.11.1, because this version is the latest release version 
in github.
  
  But, the result has not changed. It still failed.
  
  
   
---Original Message---
From: "Marcus D. Leech via USRP-users" 
To: usrp-users@lists.ettus.com
Sent date: 2018-05-25 23:12:28 GMT +0900 (Asia/Seoul)
Subject: Re: [USRP-users] timed stream in USRP X310 and B210


   
 On 05/25/2018 10:06 AM, Hojoon Yang via USRP-users wrote: 
 


In addition, USRP X310 + 2 UBX-160 v2 
 
 
 
   ---원본메일--- 
   보낸사람 : Hojoon Yang via USRP-users 
   
   받는사람: 
  usrp-users@lists.ettus.com 
   보낸날짜: 2018-05-25 20:59:17 GMT +0900 (Asia/Seoul) 
   제목: [USRP-users]timed stream in USRP X310 and B210 
  
 Hi, 
  
 I am currently using UHD 3.11.0.1 and I have two USRPs, B210 and X310. 
  
 while executing the tx_timed_samples in the example, the behavior of the 
send() function was different between B210 and X310. 
  
 More specifically, 
  
 In B210, I do ./tx_timed_samples --rate 1e6 --secs 8 --nsamps 100 
--args name=MyB210 
   
 The host does not send "whole samples" at the beginning, which means that 
the send() got stuck when the buffer in the USRP is full. 
   
 When the times up, the USRP transmitted the samples and the send function 
push the samples to the USRP again. 
  
 However, In X310, I did exact same command except the --args, 
  
 but the results are quite different. the send() is flushing "all the 
samples" to the USRP at the beginning. I don't believe the USRP X310 has a huge 
buffer to handle the 1,000,000 samples. 
 
The USRP doesn't, but the operating system network stack does.   The buffer 
dynamics of USB vs the network interface are quite different. 


 
   
 Anyway the result is failed in X310 case. i.e. I got "Waiting for async 
burst ACK... failed". 
 
Could you try reverting to a 3.10 UHD, or the latest (3.12) ? 




 
   
 But in B210 I got success flag. 
   
 the X310 is connected to the host PC with 1G ethernet cable. 
   
 What did I wrong? 
   
 Regards, 
   
 Hojoon 
  
 
 
 
 
 
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
 


   
  
 
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Complex signal representation?

2018-06-04 Thread Hojoon Yang via USRP-users

Hi all,I'm using two B210 USRPs which are connected each other through coaxial 
cable with a 30dB attenuator.I generated a simple sinusoidal wave using 
MATLAB(i.e. cosine wave, fc=100) and saved it as complex float binary form.The 
reason I stored the samples as *complex float" is that there is no real float 
type in the UHD.I have seen that uhd always take the samples as complex!Anyway, 
I stored the samples in the following way: samples(4bytes) 0(4byte) 
samples(4bytes) 0(4bytes) samples(4bytes) 0(4byte)...Now, I ran 
tx_samples_from_file example on the one USRP and rx_samples_to_file on the 
other USRP.I expected that there will be only In-phase samples in the received 
file and all zero data in the quadrature samples. Because I send it such 
way.However, this figure is what I get: both In-phase and quadrature exist. I 
know it is not a bug at all, but don't know why this happens. Is this related 
with complex signal representation?Q2. why they are different? red one is quite 
pretty, but blue one is not. blue one is real and red one is imag.Both USRPs 
are connected to an external 10 MHz.Thanks!

fig.png
Description: Binary data
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Complex signal representation?

2018-06-04 Thread Hojoon Yang via USRP-users

Hi Marcus,Thanks for your reply :)
---Original Message---From: 
MarcusMüllerTo: Hojoon Yang 
,usrp-users@lists.ettus.comSent date: 2018-06-04 
20:37:04 GMT +0900 (Asia/Seoul)Subject: Re: [USRP-users] Complex signal 
representation?

  Hi Hojoon, 

   well, the point is that USRPs deal with *complex baseband*, so, of 
   course, all the samples are complex :) 

   Q1 
   So, yeah, this is all due to complex signal representation. To 
   understand this, there's no way around understanding complex equivalent 
   baseband, but don't fret, any communications basics textbook I've ever 
   seen does that! 
   What happens is that your cosine (cos x = 1/2(e^{jx}+e^{-jx}) ) 
   undergoes a random phase change; that's perfectly normal and not a 
   problem at all, once you've gotten used to understanding signals in 
   complex baseband. 

   Q2 
   basically the same as Q1: These two *shouldn't* have the same 
   amplitude. All is good once you consider the shape of the complex 
   baseband representation of a phase-shifted cosine. It will probably 
   help if you, as I did above, consider the real cosine as the sum of two 
   complex sinusoids and consider what happens to each one of them when 
   mixed up and down with a quadrature mixer with a fixed phase offset. 
   Again, this is absolutely textbook stuff, and since you're writing from 
   a university address, I'd recommend you use the literature that is 
   recommended in the communications basics lecture. If there's no such 
   lecture at your university, GNU Radio does have a recommended reading 
   page: 

  https://wiki.gnuradio.org/index.php/SuggestedReading 

   Best regards, 
   Marcus 

   On Mon, 2018-06-04 at 20:07 +0900, Hojoon Yang via USRP-users wrote: 
   > Hi all, 
   > I'm using two B210 USRPs which are connected each other through 
   > coaxial cable with a 30dB attenuator. 
   > I generated a simple sinusoidal wave using MATLAB(i.e. cosine wave, 
   > fc=100) and saved it as complex float binary form. 
   > The reason I stored the samples as *complex float" is that there is 
   > no real float type in the UHD. 
   > I have seen that uhd always take the samples as complex! 
   > Anyway, I stored the samples in the following way: samples(4bytes) 
   > 0(4byte) samples(4bytes) 0(4bytes) samples(4bytes) 0(4byte)... 
   > 
   > Now, I ran tx_samples_from_file example on the one USRP and 
   > rx_samples_to_file on the other USRP. 
   > I expected that there will be only In-phase samples in the received 
   > file and all zero data in the quadrature samples. Because I send it 
   > such way. 
   > However, this figure is what I get: both In-phase and quadrature 
   > exist. 
   > I know it is not a bug at all, but don't know why this happens. Is 
   > this related with complex signal representation? 
   > 
   > Q2. why they are different? red one is quite pretty, but blue one is 
   > not. blue one is real and red one is imag. 
   > 
   > Both USRPs are connected to an external 10 MHz. 
   > 
   > Thanks! 
   > 
   > ___ 
   > USRP-users mailing list 
   > USRP-users@lists.ettus.com 
   > 
  http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com 

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] timed transmission LATE issue

2018-07-05 Thread Hojoon Yang via USRP-users

Hi,I am using USRP X310 with two UBX-160 daughterboards.In my application, I am 
using timed transmission, for example,start transmission at 
(usrp_get_time_now() + delta)My question is, what is the smallest delta value 
that can be successful in the *real world*? Theoretically, the delta can be any 
value, if the host can send the packet to the USRP fast enough.Suppose we have 
a PC which have i7-8700k CPU and the PC only runs this application. when I set 
the delta 1ms, Can I avoid late 'L'?Best regards,Hojoon___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] timed transmission LATE issue

2018-07-05 Thread Hojoon Yang via USRP-users

Hi, Derek.Thanks for detailed answer.I'm using ubuntu 14.04 and kernel version 
4.2.0-42-generic and USRP X300 with two UBX-160 which is connected to the host 
PC via 1G ethernet.In my application, the lowest delta value that works 
reliably is 20ms. The definition of reliability means that there is no 'L' for 
one minute during the execution of the application.I want the delta value to be 
3~4 ms.so, since the problem is latency in OS side, I cannot improve the delta 
value even if I upgrade my host PC to good one. Am I right?the number of thread 
in the application may affect the latency? My application use two thread only. 
Since there are 4 cores in my host PC, I believe it barely affects the 
latency.To sum it up, to achieve 3~4 ms delta value (based on your delta 
value(5~20ms), I believe 3~4ms delta can be achieved), I should change the OS 
in the host PC to low latency linux kernel.Please correct me if I'm wrong. 
Thanks again!
---Original Message---From: Derek Kozel 
To: Hojoon Yang CC: usrp-users 
Sent date: 2018-07-05 22:11:03 GMT +0900 
(ROK)Subject: Re: [USRP-users] timed transmission LATE issue
 
 
  
   

 
  
   Hello Hojoon,
   
   
  You will have to profile your system to determine the minimum delta that 
works reliably on your system, as well as choosing a definition for reliable. 
Networking stacks nearly always have stochastic delays due to the various 
context switches and scheduling issues with transferring data to and from a 
user program and the actual network hardware. On the USRP side the FPGA 
provides a much more deterministic behavior because the logic is exclusively 
serving the network traffic. The DRAM buffer on the transmit side is there to 
absorb some of the variability of the host computer network stack, but it can 
only do that if there is enough time delay between samples being sent by the 
program and when the DAC must be producing the associated analog signal.
  
  
 In practice I have always used a few (5-20) ms and found it to be reliable 
for transmissions lasting up to an hour, but you will have to test your 
specific setup. Different OS network stacks have different options for tuning 
to reduce both the average and peak latency of the network drivers. I'm not an 
expert in them but there are a variety of good resources online. In 
applications demanding both small latency and high reliability moving to a 
realtime Linux environment can help in meeting those hard deadlines. I believe 
that some of the LTE and GSM projects have been successful with that approach.
 
 
Regards,

   Derek
   
  
  
   
   
On Thu, Jul 5, 2018 at 12:34 PM, Hojoon Yang via USRP-users 
 wrote:


 Hi,
 
 I am using USRP X310 with two UBX-160 daughterboards.
 
 In my application, I am using timed transmission, for example,
 
 start transmission at (usrp_get_time_now() + delta)
 
 My question is, what is the smallest delta value that can be successful in 
the *real world*? Theoretically, the delta can be any value, if the host can 
send the packet to the USRP fast enough.
 
 Suppose we have a PC which have i7-8700k CPU and the PC only runs this 
application. when I set the delta 1ms, Can I avoid late 'L'?
 
 Best regards,
 Hojoon 
 
 __
 _
  USRP-users mailing list
  
 USRP-users@lists.ettus.com
  
 http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
  
 

   
   
   
 
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Synchronizing channels in USRP X310

2018-07-15 Thread Hojoon Yang via USRP-users

Hi,I'm using a USRP X310 + 2 UBX-160 for 2x2 MIMO application.For synchronizing 
4 channels(2 TX, 2 RX) in the USRP X310, I read the manual[1] and perform the 
following.set_time_unknown_pps()set_tx_rate(rate)set_rx_rate(rate)uhd::time_spec_t
 cmd_time = usrp->get_time_now() + 
uhd::time_spec_t(0.1);usrp->set_command_time(cmd_time);usrp->set_tx_freq(1820e6,
 0);usrp->set_tx_freq(1820e6, 1);usrp->set_rx_freq(1725e6, 
0);usrp->set_rx_freq(1725e6, 1);usrp->clear_command_time();1. I'm wondering 
that is this enough for synchronizing 4 channels in the USRP X310??2. Do I need 
to set sampling rate simultaneously? Like frequency? For 
example,uhd::time_spec_t cmd_time = usrp->get_time_now() + 
uhd::time_spec_t(0.1);usrp->set_command_time(cmd_time);set_tx_rate(rate)set_rx_rate(rate)usrp->clear_command_time();Thanks.[1]
 https://files.ettus.com/manual/page_sync.html___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Synchronizing channels in USRP X310

2018-07-20 Thread Hojoon Yang via USRP-users

Hi, all.Can anyone confirm this please?Thanks!
---원본메일---보낸사람 : Hojoon Yang via 
USRP-users 받는사람: usrp-users 
보낸날짜: 2018-07-15 19:36:08 GMT +0900 (ROK)제목: 
[USRP-users]Synchronizing channels in USRP X310
 
 
  Hi,
  
  I'm using a USRP X310 + 2 UBX-160 for 2x2 MIMO application.
  For synchronizing 4 channels(2 TX, 2 RX) in the USRP X310, I read the 
manual[1] and perform the following.
  
  set_time_unknown_pps()
  set_tx_rate(rate)
  set_rx_rate(rate)
  uhd::time_spec_t cmd_time = usrp->get_time_now() + uhd::time_spec_t(0.1);
  usrp->set_command_time(cmd_time);
  usrp->set_tx_freq(1820e6, 0);
  usrp->set_tx_freq(1820e6, 1);
  usrp->set_rx_freq(1725e6, 0);
  usrp->set_rx_freq(1725e6, 1);
  usrp->clear_command_time();
  
  1. I'm wondering that is this enough for synchronizing 4 channels in the USRP 
X310??
  2. Do I need to set sampling rate simultaneously? Like frequency? For example,
  
  uhd::time_spec_t cmd_time = usrp->get_time_now() + uhd::time_spec_t(0.1);
  usrp->set_command_time(cmd_time);
  set_tx_rate(rate)
  set_rx_rate(rate)
  usrp->clear_command_time();
  
  Thanks.
  
  
  [1] https://files.ettus.com/manual/page_sync.html 
  
 
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] give lo offset to uhd_tune_request_t

2018-08-16 Thread Hojoon Yang via USRP-users

Hi, allI want to give *lo offset* for tune_request.In C++, I'm able to set the 
lo_offset for tune_request, i.e. uhd::tune_request_t tune_request(target_freq, 
lo_offset)In C, How can I achieve this using 
uhd_tune_request_t?uhd_tune_request_t tune_request = {    .target_freq = 
target_freq,    .rf_freq_policy = UHD_TUNE_REQUEST_POLICY_AUTO,    
.dsp_freq_policy = UHD_TUNE_REQUEST_POLICY_AUTO};Thanks.___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] give lo offset to uhd_tune_request_t

2018-08-18 Thread Hojoon Yang via USRP-users

Hi,Who should I send it to figure this out? Any recommendation?Thanks
---Original Message---From: "Marcus D. 
Leech via USRP-users" To: 
usrp-users@lists.ettus.comSent date: 2018-08-17 03:39:21 GMT +0900 
(Asia/Seoul)Subject: Re: [USRP-users] give lo offset to uhd_tune_request_t
  
   
  
  
  
   On 08/16/2018 01:38 PM, Hojoon Yang via USRP-users wrote:

   
   
   Hi, all 

   I want to give *lo offset* for tune_request. 

   In C++, I'm able to set the lo_offset for tune_request, i.e. 
uhd::tune_request_t tune_request(target_freq, lo_offset) 
 
   In C, How can I achieve this using uhd_tune_request_t? 

   uhd_tune_request_t tune_request = { 
       .target_freq = target_freq, 
       .rf_freq_policy = UHD_TUNE_REQUEST_POLICY_AUTO, 
       .dsp_freq_policy = UHD_TUNE_REQUEST_POLICY_AUTO 
   }; 

   Thanks. 
   

   Indeed, I can't quite figure this out myself, despite spending some time 
with the C part of the codebase.   I think the function templates are
     automatically generated during build time from the C++ headers.
   
   Perhaps someone in R&D can comment on how this is done for C++ methods that 
are overloaded with respect to argument types.
   
   
 
 
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

38 matches

Mail list logo