date:20180309

Sam,

Sorry I haven't gotten back -- it sounds like you're doing everything
right. The usual quick fixes probably don't apply here. I haven't had time
to look more in depth into it, or to try to replicate it on my own hardware.

Marcus is right -- the E3xx uses an idle image in order to reduce power
consumption when the radio is inactive. I'm not sure if there's a flag that
will tell UHD not to load the idle image.

Nick

On Thu, Mar 8, 2018 at 9:30 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 03/09/2018 12:11 AM, Samuel Prager via USRP-users wrote:
>
> Still looking for more info on this problem.
>
> I have the exact same RfNoC block/software program running on an X300 and
> see no such jumps or otherwise unexpected behavior.
>
> I have attempted to isolate this issue on the E312 by creating the device3
> with the *“no_reload_fpga”* flag. (Appropriate image is loaded before
> hand with the uhd_usrp_image_loader. Running my program the first time
> works as expected, but if I kill the program and restart, I get this error:
>
> *“AssertionError: zf_peek32(ctrl_base+ARBITER_RB_ADDR_SPACE) > 0 in
> virtual void e300_fifo_mb::release()"*
>
> The last few lines in the Uhd log file are:
>
>
>
>
>
>
>
>
>
> *e300_impl.cpp:639,1,E300,[E300] Setting up dest map for host ep 0 to be
> stream 0 device3_impl.cpp:131,0, DEVICE3, Setting up NoC-Shell Control for
> port #0 (SID; 00:00>02:10) device3_impl.cpp:139,0,DEVICE3, OK
> davice3_impl.cpp:141,0, DEVICE3, Port 16: found NoC-Block with ID
> 12AD1000. e300_impl.cpp:639,1,E300, [E300] Setting up dest map for
> host ep 1 to be stream 1 device3_impl.cpp:160,0,DEVICE3, Setting up NoC
> Shell port for #1 (SID: 00:01>02:11)*
>
>
>
> Shouldn’t the E312 be able to operate without needing to reload the FPGA
> image each time? Has this been tested? I would really appreciate any hints
> or pointers into why this is happening.
>
> Thank you,
>
> Sam
>
> The E3xx run an "idle" image when the device is not being used.  I cannot
> remember the reason for that, TBH.
>
>
> ___
> 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] Multi N200 issues

2018-03-09 Thread Keith k via USRP-users

Hey Nick

Thanks for taking some time to help with this. Our CPU is an AMD Ryzen 7
1700X Eight-Core Processor. I tried UHD 3.9-LTS and I get some interesting
results. I got much more lates on TX and nothing looked correct on the
scope until I used a minimum of 50ms delay in the future. The UHD
application also massively oversubscribed my cpu using this version. My
program was still getting lates on RX after a few minutes of runtime. I
also still get sequence errors too. Here is the line from the output of top.

PID USER  PR  NIVIRTRESSHR S   %CPU  %MEM TIME+ COMMAND
5884 radar 20   0 1754.2m  69.3m  12.2m S 1002.3 0.432   2:25.56
test_rx_tx

For comparison 3.10 does not give the same oversubscription.

PID USER  PR  NIVIRTRESSHR S   %CPU  %MEM TIME+ COMMAND
31543 radar 20   0  524.9m  71.6m  13.9m S 51.495 0.446   0:11.02
test_rx_tx

I also tried the new version of UHD, 3.11 and I get an error that it can't
recognize the GPIO bank I've been using
[INFO] [UHD] linux; GNU C++ version 4.8.5; Boost_105400;
UHD_3.11.0.HEAD-0-g13c32cef
[INFO] [USRP2] Opening a USRP2/N-Series device...
[INFO] [USRP2] Current recv frame size: 1472 bytes
[INFO] [USRP2] Current send frame size: 1472 bytes
[INFO] [MULTI_USRP] 1) catch time transition at pps edge
[INFO] [MULTI_USRP] 2) set times next pps (synchronously)
Error: RuntimeError: The hardware has no gpio bank: RXA:

I commented out those lines for now and tried running. With UHD 3.11, the
application appears to be running, but I see nothing on USRPs to indicate
things are working. The TX/RX leds don't light up nor do I see RF output on
the scope. The UHD application is still throwing out sequence errors and a
few underflow errors.

On Thu, Mar 8, 2018 at 4:06 PM, Nate Temple  wrote:

> Hi Keith,
>
> Can you please give UHD 3.9.7 or the 3.9-LTS branch of a try with your
> setup?
>
> What kind of CPU does your host have? What is the load profile while your
> application is running?
>
> Regards,
> Nate Temple
>
> On Thu, Mar 8, 2018 at 1:55 PM, Keith k via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hey all
>>
>> Just wondering if anyone had a chance to look at this for me. I'd
>> appreciate it immensely! Thank you.
>>
>> On Fri, Mar 2, 2018 at 3:37 PM, Keith k  wrote:
>>
>>> Hello all
>>>
>>> I'm working on a project to use 16 N200s in a multi USRP configuration
>>> for a radar project. They are synchronized using 3 Octoclocks (one master
>>> with a GPSDO, and two slaves that drive the 16 N200s). I've been getting
>>> many errors that I was hoping someone could help with. I have attached a
>>> sample program that mimics how the USRPs are used. The basic goal here is
>>> to sample a determined number of samples while transmitting some spaced
>>> pulses (a "pulse sequence") and then repeat. It would be beneficial to have
>>> as little delay as possible in between loops. I've been running into some
>>> problems however.
>>>
>>> BASIC INFO
>>>   We have 16 N200s + 1 spare
>>>   3 Octoclocks (1 has gps and it drives the other two)
>>>   LFTX and LFRX daughterboards in each N200
>>>   linux; GNU C++ version 4.8.5; Boost_105400;
>>> UHD_003.010.002.000-0-gbd6e21dc
>>>   Intel Corporation Ethernet Controller 10-Gigabit X540-AT2
>>>   Devices are all connected via 3 daisy chained Netgear XS708E switches
>>>   Ideal sampling rates: 5-10MHz TX, 5-10MHz RX depending on
>>> hardware/software limitations.
>>>
>>> One of the issues I sometimes get after several minutes of runtime (or
>>> several thousand pulse sequences) is the overflow(O) with the out of
>>> sequence flag set in the rx metadata. I also get sequence errors(S) on the
>>> tx side too. It seems to happen more often and faster with higher sampling
>>> rate. I've gathered from other mailing list posts that this is likely a
>>> network configuration issue. Can someone recommend a known working computer
>>> build and network configuration that can handle the amount of USRPs and
>>> data we are attempting to use?
>>>
>>> Another major issue I eventually get during runtime is a slurry of
>>> lates(L) on TX and then a LATE in the RX metadata. I've tried increasing
>>> the time in the future that the TX/RX should start (from when the stream
>>> commands are called) and I've tried to minimize the number of operations
>>> happening between that calculation and when TX/RX start, but the lates
>>> still eventually happen. I've tried to time profile what I can in my code
>>> and it seems I should really only need about ~0.5ms of delay, but even at
>>> 3-10ms of delay I have issues. I feel like 10ms of time should be more that
>>> plenty of time for the host to issue stream commands. I don't seem to get
>>> lates if I have test applications that individually test TX or RX, but when
>>> I put them together using threads, I can't seem to find a way to eliminate
>>> the lates. Any ideas on how I should set up what I'm trying to do here?
>>>
>>> Here is the compiler line to make

Re: [USRP-users] GRC + RFNoC + Radio Loopback

You're going to have to ask a better question than that. Please provide the
following:

* What you are trying to accomplish
* What hardware you are using
* What UHD and Gnuradio version you are using
* The approach you followed
* The result you expected
* The result you actually got
* A flowgraph which exhibits the problem

If you put effort into your question, we can put effort into answering you.

Nick

On Thu, Mar 8, 2018 at 10:39 AM Kei Nguyen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello, is this problem resolved? I am facing the same issue in the last
> email. Also, I tried to receive the relay signal with another usrp but it
> doesn't receive anything in my transmit frequency.
>
> Hai
> ___
> 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] A question about accessing registers on a device3

2018-03-09 Thread Taliver Heath via USRP-users

And I was able to solve my own problem after I got over the fear of
bricking. :)

Yes, sr_write writes, while user_reg_read reads, and the offset is totally
dependent upon the FPGA implementation. (Noted for future people searching).

On Fri, Mar 9, 2018 at 8:55 AM, Taliver Heath  wrote:

> We built an FPGA version off of the radio_block, re-using the registers as:
>
> SR_BASE = 160
> SR_DB_GPIO= SR_BASE + 8’d32   = 192
> SR_THRESHOLD   =SR_BASE + 8'd40;
> ...etc
>
> RB_MISC_IO   = RB_BASE + 0;
> RB_SPI   = RB_BASE + 1;
> RB_LEDS  = RB_BASE + 2;
> ..etc
>
> But now I'm having a real tough time finding the documentation on
> reading/writing these.  Right now I have gotten to:
>
> auto usrp = uhd::device3::make(addr_string);
> uhd::rfnoc::block_id_t radio_ctrl_id(0, "Radio");
> auto radio = usrp->get_block_ctrl(radio_ctrl_id);
>
> and then I'm using:
> radio->user_reg_read64(addr);
>
> To read the registers -- Where addr == 24 to read the SB_DB_GPIO for
> example.
>
> But now I'm really struggling on how to write these values -- is this a
> two step write on the settings bus, and is there a better way to understand
> the mapping?
>
> (The real answer would be to fix the xml most likely, but I'm hoping to
> not go down that path quite yet.)
>
> Thanks.
>
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E312 Loopback Path Delay Changes when FPGA image is reloaded

2018-03-09 Thread Samuel Prager via USRP-users

Hey Nick,

No prob blew at all. The flag “no_reload_fpga” seems to work for that. The 
bigger problem is that each time the fpga image is loaded on the e3xx, the 
relative path delays between the RXA and RXB channels changes randomly as seen 
by the sample group jumps in the image I originally attached. The random LO 
phase is measured and removed, so there is something else happening in this 
strange case.

If anyone has any ideas as to what could be causing this please help! The phase 
stability of the E312 is amazing within the same fpga image cycle but these 
relatively large jumps after reload/ power cycle are a deal breaker for some 
applications!

Thanks

Sam

On Mar 9, 2018, 9:19 AM -0800, Nick Foster via USRP-users 
, wrote:
> Sam,
>
> Sorry I haven't gotten back -- it sounds like you're doing everything right. 
> The usual quick fixes probably don't apply here. I haven't had time to look 
> more in depth into it, or to try to replicate it on my own hardware.
>
> Marcus is right -- the E3xx uses an idle image in order to reduce power 
> consumption when the radio is inactive. I'm not sure if there's a flag that 
> will tell UHD not to load the idle image.
>
> Nick
>
> > On Thu, Mar 8, 2018 at 9:30 PM Marcus D. Leech via USRP-users 
> >  wrote:
> > > On 03/09/2018 12:11 AM, Samuel Prager via USRP-users wrote:
> > > > Still looking for more info on this problem.
> > > >
> > > > I have the exact same RfNoC block/software program running on an X300 
> > > > and see no such jumps or otherwise unexpected behavior.
> > > >
> > > > I have attempted to isolate this issue on the E312 by creating the 
> > > > device3 with the “no_reload_fpga” flag. (Appropriate image is loaded 
> > > > before hand with the uhd_usrp_image_loader. Running my program the 
> > > > first time works as expected, but if I kill the program and restart, I 
> > > > get this error:
> > > >
> > > > “AssertionError: zf_peek32(ctrl_base+ARBITER_RB_ADDR_SPACE) > 0 in 
> > > > virtual void e300_fifo_mb::release()"
> > > >
> > > > The last few lines in the Uhd log file are:
> > > >
> > > >
> > > > e300_impl.cpp:639,1,E300,[E300] Setting up dest map for host ep 0 to be 
> > > > stream 0
> > > >
> > > > device3_impl.cpp:131,0, DEVICE3, Setting up NoC-Shell Control for port 
> > > > #0 (SID; 00:00>02:10)
> > > > device3_impl.cpp:139,0,DEVICE3, OK
> > > > davice3_impl.cpp:141,0, DEVICE3, Port 16: found NoC-Block with ID 
> > > > 12AD1000.
> > > > e300_impl.cpp:639,1,E300, [E300] Setting up dest map for host ep 1 to 
> > > > be stream 1
> > > >
> > > > device3_impl.cpp:160,0,DEVICE3, Setting up NoC Shell port for #1 (SID: 
> > > > 00:01>02:11)
> > > >
> > > >
> > > >
> > > > Shouldn’t the E312 be able to operate without needing to reload the 
> > > > FPGA image each time? Has this been tested? I would really appreciate 
> > > > any hints or pointers into why this is happening.
> > > >
> > > > Thank you,
> > > >
> > > > Sam
> > > >
> > > The E3xx run an "idle" image when the device is not being used.  I cannot 
> > > remember the reason for that, TBH.
> > >
> > >
> > > ___
> > > 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
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com&d=DwICAg&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=opIuWAKmywF059tAs2i3Pg&m=HkJbIenCP1t5oGgIxFFvHftFEabvbCk9VlUuv6EBHqA&s=HutNULVtirv0JuQ4R8HiR34nBs82dDVsc3zQccm3BTU&e=
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] E312 Loopback Path Delay Changes when FPGA image is reloaded

One thing that struck me: I don't think you should have to disable the
streamer to switch between cal and radio channels. Just for experiment's
sake, try leaving both channels active in the streamer. You can pull
samples from both channels in your recv() command, and just use the channel
you're interested in. Does doing this affect the result?

Nick

On Fri, Mar 9, 2018 at 10:13 AM Samuel Prager  wrote:

> Hey Nick,
>
> No prob blew at all. The flag *“no_reload_fpga”* seems to work for that.
> The bigger problem is that each time the fpga image is loaded on the e3xx,
> the relative path delays between the RXA and RXB channels changes randomly
> as seen by the sample group jumps in the image I originally attached. The
> random LO phase is measured and removed, so there is something else
> happening in this strange case.
>
> If anyone has any ideas as to what could be causing this please help! The
> phase stability of the E312 is amazing within the same fpga image cycle but
> these relatively large jumps after reload/ power cycle are a deal breaker
> for some applications!
>
> Thanks
>
> Sam
>
> On Mar 9, 2018, 9:19 AM -0800, Nick Foster via USRP-users <
> usrp-users@lists.ettus.com>, wrote:
>
> Sam,
>
> Sorry I haven't gotten back -- it sounds like you're doing everything
> right. The usual quick fixes probably don't apply here. I haven't had time
> to look more in depth into it, or to try to replicate it on my own hardware.
>
> Marcus is right -- the E3xx uses an idle image in order to reduce power
> consumption when the radio is inactive. I'm not sure if there's a flag that
> will tell UHD not to load the idle image.
>
> Nick
>
> On Thu, Mar 8, 2018 at 9:30 PM Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 03/09/2018 12:11 AM, Samuel Prager via USRP-users wrote:
>>
>> Still looking for more info on this problem.
>>
>> I have the exact same RfNoC block/software program running on an X300 and
>> see no such jumps or otherwise unexpected behavior.
>>
>> I have attempted to isolate this issue on the E312 by creating the
>> device3 with the *“no_reload_fpga”* flag. (Appropriate image is loaded
>> before hand with the uhd_usrp_image_loader. Running my program the first
>> time works as expected, but if I kill the program and restart, I get this
>> error:
>>
>> *“AssertionError: zf_peek32(ctrl_base+ARBITER_RB_ADDR_SPACE) > 0 in
>> virtual void e300_fifo_mb::release()"*
>>
>> The last few lines in the Uhd log file are:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *e300_impl.cpp:639,1,E300,[E300] Setting up dest map for host ep 0 to be
>> stream 0 device3_impl.cpp:131,0, DEVICE3, Setting up NoC-Shell Control for
>> port #0 (SID; 00:00>02:10) device3_impl.cpp:139,0,DEVICE3, OK
>> davice3_impl.cpp:141,0, DEVICE3, Port 16: found NoC-Block with ID
>> 12AD1000. e300_impl.cpp:639,1,E300, [E300] Setting up dest map for
>> host ep 1 to be stream 1 device3_impl.cpp:160,0,DEVICE3, Setting up NoC
>> Shell port for #1 (SID: 00:01>02:11)*
>>
>>
>>
>> Shouldn’t the E312 be able to operate without needing to reload the FPGA
>> image each time? Has this been tested? I would really appreciate any hints
>> or pointers into why this is happening.
>>
>> Thank you,
>>
>> Sam
>>
>> The E3xx run an "idle" image when the device is not being used.  I cannot
>> remember the reason for that, TBH.
>>
>>
>> ___
>> 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
>
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com&d=DwICAg&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=opIuWAKmywF059tAs2i3Pg&m=HkJbIenCP1t5oGgIxFFvHftFEabvbCk9VlUuv6EBHqA&s=HutNULVtirv0JuQ4R8HiR34nBs82dDVsc3zQccm3BTU&e=
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] GRC + RFNoC + Radio Loopback

2018-03-09 Thread Kei Nguyen via USRP-users

Thanks for the reply and sorry for not providing much information. My case
is that I want to do a relay transmission with the setup: USRP 1 transmits
--> USRP 2 receives and retransmits with a shifted fc --> USRP 3 receives.
The problem is in USRP 2, as you pointed out in your post. I'm testing on a
simple flowgraph RX --> DDC --> DmaFIFO --> DUC (frequency shifted by 5MHz)
--> TX. I used your approach [1] in step 1 of your tutorial (also did step
2 and 3) and rebuilt.
At first the flowgraph runs without errors. The TX and RX lights were on,
so it seemed to transmit something. But in USRP 3 I didn't see the relay
signals (only the original signal that USRP1 transmits).
Also, in the following runs, it raised the errors:
[INFO] [UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_4.0.0.rfnoc-devel-409-gec9138eb]
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Determining maximum frame size...
[INFO] [X300] Maximum frame size: 1472 bytes.
[INFO] [X300] Setup basic communication...
[INFO] [X300] Loading values from EEPROM...
[INFO] [X300] Setup RF frontend clocking...
[INFO] [X300] Radio 1x clock:200
[INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 0...
[INFO] [RFNOC] pass (Throughput: 1302.9MB/s)
[INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 1...
[INFO] [RFNOC] pass (Throughput: 1293.6MB/s)
[INFO] [RFNOC RADIO] Register loopback test passed
[INFO] [RFNOC RADIO] Register loopback test passed
[INFO] [RFNOC RADIO] Register loopback test passed
[INFO] [RFNOC RADIO] Register loopback test passed
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
[INFO] [RFNOC] Assuming max packet size for 0/DDC_0
[INFO] [RFNOC] Assuming max packet size for 0/DmaFIFO_0
[INFO] [RFNOC] Assuming max packet size for 0/DUC_0
[INFO] [RFNOC] Assuming max packet size for 0/Radio_0
kei@kei-Precision-T7610:~/test_rfnoc$ ./relay.py
[INFO] [UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_4.0.0.rfnoc-devel-409-gec9138eb]
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Determining maximum frame size...
[INFO] [X300] Maximum frame size: 1472 bytes.
[INFO] [X300] Setup basic communication...
[INFO] [X300] Loading values from EEPROM...
[INFO] [X300] Setup RF frontend clocking...
[INFO] [X300] Radio 1x clock:200
[ERROR] [UHD] Exception caught in safe-call.
  in virtual ctrl_iface_impl::~ctrl_iface_impl()
  at /home/kei/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> EnvironmentError: IOError: Block ctrl (CE_00_Port_30)
packet parse error - EnvironmentError: IOError: Expected packet index: 3
Received index: 4
Traceback (most recent call last):
  File "./relay.py", line 291, in 
main()
  File "./relay.py", line 279, in main
tb = top_block_cls(freq=options.freq)
  File "./relay.py", line 72, in __init__
self.device3 = device3 = ettus.device3(uhd.device_addr_t(
",".join(('type=x300', "")) ))
  File "/home/kei/rfnoc/lib/python2.7/dist-packages/ettus/ettus_swig.py",
line 1610, in make
return _ettus_swig.device3_make(device_addr)
RuntimeError: EnvironmentError: IOError: [0/DmaFIFO_0] sr_read64() failed:
EnvironmentError: IOError: Block ctrl (CE_00_Port_30) packet parse error -
EnvironmentError: IOError: Expected SID: 02:30>00:00  Received SID:
02:c0>00:00


which is exactly the errors that Christophe faced in the previous post. I
had to power cycle to run the flowgraph again.
Attachments are the changed files. I'm using uhd version UHD
4.0.0.rfnoc-devel-409-gec9138eb and gnuradio version
3.7.12git-295-ga0adcd33.
Sorry for the long post.



On Fri, Mar 9, 2018 at 12:21 PM, Nick Foster  wrote:

> You're going to have to ask a better question than that. Please provide
> the following:
>
> * What you are trying to accomplish
> * What hardware you are using
> * What UHD and Gnuradio version you are using
> * The approach you followed
> * The result you expected
> * The result you actually got
> * A flowgraph which exhibits the problem
>
> If you put effort into your question, we can put effort into answering you.
>
> Nick
>
> On Thu, Mar 8, 2018 at 10:39 AM Kei Nguyen via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hello, is this problem resolved? I am facing the same issue in the last
>> email. Also, I tried to receive the relay signal with another usrp but it
>> doesn't receive anything in my transmit frequency.
>>
>> Hai
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
#!/usr/bin/env python2
# -*- coding: utf-8 -*-
##
# GNU Radio Python Flow Graph
# Title: Relay
# Generated: Fri Mar  9 13:08:00 2018
##

if __name__ == '__main__':
import ctypes
import sys
if sys.platform.startswith('linux'):
try:

Re: [USRP-users] GRC + RFNoC + Radio Loopback

Are you using a custom FPGA image? What happens if you just omit the DMA
FIFO?

Also, set a reasonable spp in your RX Radio block arguments -- 300 to 600
is a good start.

Nick

On Fri, Mar 9, 2018 at 10:24 AM Kei Nguyen 
wrote:

> Thanks for the reply and sorry for not providing much information. My case
> is that I want to do a relay transmission with the setup: USRP 1 transmits
> --> USRP 2 receives and retransmits with a shifted fc --> USRP 3 receives.
> The problem is in USRP 2, as you pointed out in your post. I'm testing on
> a simple flowgraph RX --> DDC --> DmaFIFO --> DUC (frequency shifted by
> 5MHz) --> TX. I used your approach [1] in step 1 of your tutorial (also did
> step 2 and 3) and rebuilt.
> At first the flowgraph runs without errors. The TX and RX lights were on,
> so it seemed to transmit something. But in USRP 3 I didn't see the relay
> signals (only the original signal that USRP1 transmits).
> Also, in the following runs, it raised the errors:
> [INFO] [UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_4.0.0.rfnoc-devel-409-gec9138eb]
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Determining maximum frame size...
> [INFO] [X300] Maximum frame size: 1472 bytes.
> [INFO] [X300] Setup basic communication...
> [INFO] [X300] Loading values from EEPROM...
> [INFO] [X300] Setup RF frontend clocking...
> [INFO] [X300] Radio 1x clock:200
> [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 0...
> [INFO] [RFNOC] pass (Throughput: 1302.9MB/s)
> [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 1...
> [INFO] [RFNOC] pass (Throughput: 1293.6MB/s)
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [CORES] Performing timer loopback test...
> [INFO] [CORES] Timer loopback test passed
> [INFO] [CORES] Performing timer loopback test...
> [INFO] [CORES] Timer loopback test passed
> [INFO] [RFNOC] Assuming max packet size for 0/DDC_0
> [INFO] [RFNOC] Assuming max packet size for 0/DmaFIFO_0
> [INFO] [RFNOC] Assuming max packet size for 0/DUC_0
> [INFO] [RFNOC] Assuming max packet size for 0/Radio_0
> kei@kei-Precision-T7610:~/test_rfnoc$ ./relay.py
> [INFO] [UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_4.0.0.rfnoc-devel-409-gec9138eb]
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Determining maximum frame size...
> [INFO] [X300] Maximum frame size: 1472 bytes.
> [INFO] [X300] Setup basic communication...
> [INFO] [X300] Loading values from EEPROM...
> [INFO] [X300] Setup RF frontend clocking...
> [INFO] [X300] Radio 1x clock:200
> [ERROR] [UHD] Exception caught in safe-call.
>   in virtual ctrl_iface_impl::~ctrl_iface_impl()
>   at /home/kei/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
> this->peek32(0); -> EnvironmentError: IOError: Block ctrl (CE_00_Port_30)
> packet parse error - EnvironmentError: IOError: Expected packet index: 3
> Received index: 4
> Traceback (most recent call last):
>   File "./relay.py", line 291, in 
> main()
>   File "./relay.py", line 279, in main
> tb = top_block_cls(freq=options.freq)
>   File "./relay.py", line 72, in __init__
> self.device3 = device3 = ettus.device3(uhd.device_addr_t(
> ",".join(('type=x300', "")) ))
>   File "/home/kei/rfnoc/lib/python2.7/dist-packages/ettus/ettus_swig.py",
> line 1610, in make
> return _ettus_swig.device3_make(device_addr)
> RuntimeError: EnvironmentError: IOError: [0/DmaFIFO_0] sr_read64() failed:
> EnvironmentError: IOError: Block ctrl (CE_00_Port_30) packet parse error -
> EnvironmentError: IOError: Expected SID: 02:30>00:00  Received SID:
> 02:c0>00:00
>
>
> which is exactly the errors that Christophe faced in the previous post. I
> had to power cycle to run the flowgraph again.
> Attachments are the changed files. I'm using uhd version UHD
> 4.0.0.rfnoc-devel-409-gec9138eb and gnuradio version
> 3.7.12git-295-ga0adcd33.
> Sorry for the long post.
>
>
>
> On Fri, Mar 9, 2018 at 12:21 PM, Nick Foster  wrote:
>
>> You're going to have to ask a better question than that. Please provide
>> the following:
>>
>> * What you are trying to accomplish
>> * What hardware you are using
>> * What UHD and Gnuradio version you are using
>> * The approach you followed
>> * The result you expected
>> * The result you actually got
>> * A flowgraph which exhibits the problem
>>
>> If you put effort into your question, we can put effort into answering
>> you.
>>
>> Nick
>>
>> On Thu, Mar 8, 2018 at 10:39 AM Kei Nguyen via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hello, is this problem resolved? I am facing the same issue in the last
>>> email. Also, I tried to receive the relay signal with another usrp but it
>>> doesn't receive anything in my transmit frequency.
>>>
>>> Hai
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http

[USRP-users] Problem of Octoclock

2018-03-09 Thread 賴明煊 via USRP-users

Hi

Here is the situation of my Octoclock-G.
When I connect the power cable to it, four LEDs of "INTERNAL", "EXTERNAL",
"STATUS" and "POWER" lit for about 5 seconds and then only "POWER" remains
on , others become off. It seems there is nothing in operation, because I
can't feel it vibrating when I touch it.

Then I try to use the Octoclock-G to sync 2 X310 but fails.

I also connect Octoclock-G with ethernet to my PC only and I believe that I
set the IP address correctly. But "uhd_find_devices" gives me "NO UHD
Devices FOUND".

What is the possible issue?
Is my Octoclock-G broken?

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

Re: [USRP-users] GRC + RFNoC + Radio Loopback

2018-03-09 Thread Kei Nguyen via USRP-users

Thanks. After setting spp=600 and omit the DMA FIFO, it doesn't raise the
errors anymore and I can run the flowgraph without having to power cycle. I
think that is because the flow doesn't go through the host anymore. But
it's weird that after stopping the flowgraph the RX and TX lights are still
on. Why is that?
By the way still I can't receive the relay signal in USRP 3.

On Fri, Mar 9, 2018 at 1:27 PM, Nick Foster  wrote:

> Are you using a custom FPGA image? What happens if you just omit the DMA
> FIFO?
>
> Also, set a reasonable spp in your RX Radio block arguments -- 300 to 600
> is a good start.
>
> Nick
>
> On Fri, Mar 9, 2018 at 10:24 AM Kei Nguyen 
> wrote:
>
>> Thanks for the reply and sorry for not providing much information. My
>> case is that I want to do a relay transmission with the setup: USRP 1
>> transmits --> USRP 2 receives and retransmits with a shifted fc --> USRP 3
>> receives.
>> The problem is in USRP 2, as you pointed out in your post. I'm testing on
>> a simple flowgraph RX --> DDC --> DmaFIFO --> DUC (frequency shifted by
>> 5MHz) --> TX. I used your approach [1] in step 1 of your tutorial (also did
>> step 2 and 3) and rebuilt.
>> At first the flowgraph runs without errors. The TX and RX lights were on,
>> so it seemed to transmit something. But in USRP 3 I didn't see the relay
>> signals (only the original signal that USRP1 transmits).
>> Also, in the following runs, it raised the errors:
>> [INFO] [UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800;
>> UHD_4.0.0.rfnoc-devel-409-gec9138eb]
>> [INFO] [X300] X300 initialization sequence...
>> [INFO] [X300] Determining maximum frame size...
>> [INFO] [X300] Maximum frame size: 1472 bytes.
>> [INFO] [X300] Setup basic communication...
>> [INFO] [X300] Loading values from EEPROM...
>> [INFO] [X300] Setup RF frontend clocking...
>> [INFO] [X300] Radio 1x clock:200
>> [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 0...
>> [INFO] [RFNOC] pass (Throughput: 1302.9MB/s)
>> [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 1...
>> [INFO] [RFNOC] pass (Throughput: 1293.6MB/s)
>> [INFO] [RFNOC RADIO] Register loopback test passed
>> [INFO] [RFNOC RADIO] Register loopback test passed
>> [INFO] [RFNOC RADIO] Register loopback test passed
>> [INFO] [RFNOC RADIO] Register loopback test passed
>> [INFO] [CORES] Performing timer loopback test...
>> [INFO] [CORES] Timer loopback test passed
>> [INFO] [CORES] Performing timer loopback test...
>> [INFO] [CORES] Timer loopback test passed
>> [INFO] [RFNOC] Assuming max packet size for 0/DDC_0
>> [INFO] [RFNOC] Assuming max packet size for 0/DmaFIFO_0
>> [INFO] [RFNOC] Assuming max packet size for 0/DUC_0
>> [INFO] [RFNOC] Assuming max packet size for 0/Radio_0
>> kei@kei-Precision-T7610:~/test_rfnoc$ ./relay.py
>> [INFO] [UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800;
>> UHD_4.0.0.rfnoc-devel-409-gec9138eb]
>> [INFO] [X300] X300 initialization sequence...
>> [INFO] [X300] Determining maximum frame size...
>> [INFO] [X300] Maximum frame size: 1472 bytes.
>> [INFO] [X300] Setup basic communication...
>> [INFO] [X300] Loading values from EEPROM...
>> [INFO] [X300] Setup RF frontend clocking...
>> [INFO] [X300] Radio 1x clock:200
>> [ERROR] [UHD] Exception caught in safe-call.
>>   in virtual ctrl_iface_impl::~ctrl_iface_impl()
>>   at /home/kei/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
>> this->peek32(0); -> EnvironmentError: IOError: Block ctrl (CE_00_Port_30)
>> packet parse error - EnvironmentError: IOError: Expected packet index: 3
>> Received index: 4
>> Traceback (most recent call last):
>>   File "./relay.py", line 291, in 
>> main()
>>   File "./relay.py", line 279, in main
>> tb = top_block_cls(freq=options.freq)
>>   File "./relay.py", line 72, in __init__
>> self.device3 = device3 = ettus.device3(uhd.device_addr_t(
>> ",".join(('type=x300', "")) ))
>>   File "/home/kei/rfnoc/lib/python2.7/dist-packages/ettus/ettus_swig.py",
>> line 1610, in make
>> return _ettus_swig.device3_make(device_addr)
>> RuntimeError: EnvironmentError: IOError: [0/DmaFIFO_0] sr_read64()
>> failed: EnvironmentError: IOError: Block ctrl (CE_00_Port_30) packet parse
>> error - EnvironmentError: IOError: Expected SID: 02:30>00:00  Received SID:
>> 02:c0>00:00
>>
>>
>> which is exactly the errors that Christophe faced in the previous post. I
>> had to power cycle to run the flowgraph again.
>> Attachments are the changed files. I'm using uhd version UHD
>> 4.0.0.rfnoc-devel-409-gec9138eb and gnuradio version
>> 3.7.12git-295-ga0adcd33.
>> Sorry for the long post.
>>
>>
>>
>> On Fri, Mar 9, 2018 at 12:21 PM, Nick Foster 
>> wrote:
>>
>>> You're going to have to ask a better question than that. Please provide
>>> the following:
>>>
>>> * What you are trying to accomplish
>>> * What hardware you are using
>>> * What UHD and Gnuradio version you are using
>>> * The approach you followed
>>> * The result you expected
>>> * The result you actually got
>>> * A flowgraph which exhibits the problem

Re: [USRP-users] E312 Loopback Path Delay Changes when FPGA image is reloaded

2018-03-09 Thread Samuel Prager via USRP-users

Hi Nick,

I can try this, but the reason I disable one or the other streamer is so that I 
can sample at the full 50MHz. Running both streamers cuts the sample rate in 
half and I am only using the cal channel to measure/correct the random LO phase 
offset.

In this switching mode, the data always comes from radio block 1, but the 
AD9361 routes it to either RXA or RXB at full rate depending on the active 
streamer.

I also switch back and forth between the channels thousands of times on a 
single power cycle without an issue.

Even if I only receive on a single channel (RXA) and match filter with a 
reference waveform file, I am still seeing the same behavior: tight groupings 
in measured phase slope delay but with random hops in group mean whenever the 
image is reloaded.

Sam

On Mar 9, 2018, 10:22 AM -0800, Nick Foster , wrote:
> One thing that struck me: I don't think you should have to disable the 
> streamer to switch between cal and radio channels. Just for experiment's 
> sake, try leaving both channels active in the streamer. You can pull samples 
> from both channels in your recv() command, and just use the channel you're 
> interested in. Does doing this affect the result?
>
> Nick
>
> > On Fri, Mar 9, 2018 at 10:13 AM Samuel Prager  wrote:
> > > Hey Nick,
> > >
> > > No prob blew at all. The flag “no_reload_fpga” seems to work for that. 
> > > The bigger problem is that each time the fpga image is loaded on the 
> > > e3xx, the relative path delays between the RXA and RXB channels changes 
> > > randomly as seen by the sample group jumps in the image I originally 
> > > attached. The random LO phase is measured and removed, so there is 
> > > something else happening in this strange case.
> > >
> > > If anyone has any ideas as to what could be causing this please help! The 
> > > phase stability of the E312 is amazing within the same fpga image cycle 
> > > but these relatively large jumps after reload/ power cycle are a deal 
> > > breaker for some applications!
> > >
> > > Thanks
> > >
> > > Sam
> > >
> > > On Mar 9, 2018, 9:19 AM -0800, Nick Foster via USRP-users 
> > > , wrote:
> > > > Sam,
> > > >
> > > > Sorry I haven't gotten back -- it sounds like you're doing everything 
> > > > right. The usual quick fixes probably don't apply here. I haven't had 
> > > > time to look more in depth into it, or to try to replicate it on my own 
> > > > hardware.
> > > >
> > > > Marcus is right -- the E3xx uses an idle image in order to reduce power 
> > > > consumption when the radio is inactive. I'm not sure if there's a flag 
> > > > that will tell UHD not to load the idle image.
> > > >
> > > > Nick
> > > >
> > > > > On Thu, Mar 8, 2018 at 9:30 PM Marcus D. Leech via USRP-users 
> > > > >  wrote:
> > > > > > On 03/09/2018 12:11 AM, Samuel Prager via USRP-users wrote:
> > > > > > > Still looking for more info on this problem.
> > > > > > >
> > > > > > > I have the exact same RfNoC block/software program running on an 
> > > > > > > X300 and see no such jumps or otherwise unexpected behavior.
> > > > > > >
> > > > > > > I have attempted to isolate this issue on the E312 by creating 
> > > > > > > the device3 with the “no_reload_fpga” flag. (Appropriate image is 
> > > > > > > loaded before hand with the uhd_usrp_image_loader. Running my 
> > > > > > > program the first time works as expected, but if I kill the 
> > > > > > > program and restart, I get this error:
> > > > > > >
> > > > > > > “AssertionError: zf_peek32(ctrl_base+ARBITER_RB_ADDR_SPACE) > 0 
> > > > > > > in virtual void e300_fifo_mb::release()"
> > > > > > >
> > > > > > > The last few lines in the Uhd log file are:
> > > > > > >
> > > > > > >
> > > > > > > e300_impl.cpp:639,1,E300,[E300] Setting up dest map for host ep 0 
> > > > > > > to be stream 0
> > > > > > >
> > > > > > > device3_impl.cpp:131,0, DEVICE3, Setting up NoC-Shell Control for 
> > > > > > > port #0 (SID; 00:00>02:10)
> > > > > > > device3_impl.cpp:139,0,DEVICE3, OK
> > > > > > > davice3_impl.cpp:141,0, DEVICE3, Port 16: found NoC-Block with ID 
> > > > > > > 12AD1000.
> > > > > > > e300_impl.cpp:639,1,E300, [E300] Setting up dest map for host ep 
> > > > > > > 1 to be stream 1
> > > > > > >
> > > > > > > device3_impl.cpp:160,0,DEVICE3, Setting up NoC Shell port for #1 
> > > > > > > (SID: 00:01>02:11)
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Shouldn’t the E312 be able to operate without needing to reload 
> > > > > > > the FPGA image each time? Has this been tested? I would really 
> > > > > > > appreciate any hints or pointers into why this is happening.
> > > > > > >
> > > > > > > Thank you,
> > > > > > >
> > > > > > > Sam
> > > > > > >
> > > > > > The E3xx run an "idle" image when the device is not being used.  I 
> > > > > > cannot remember the reason for that, TBH.
> > > > > >
> > > > > >
> > > > > > ___
> > > > > > USRP-users mailing list
> > > > > > USRP-users@lists.ettus.com
> > > > > > http://li

Re: [USRP-users] GRC + RFNoC + Radio Loopback

2018-03-09 Thread Samuel Prager via USRP-users

Hello,

I have had this issue and may be able to help. I believe that is because the rx 
packet headers need to be modified before the radio will transmit them. I would 
suggest looking at the siggen block and making a new ‘relay’ noc block between 
the rx and tx in the fpga that modifies headers appropriately. I would guess 
that the lights are on because you have filled up all fifos.

Sam


On Mar 9, 2018, 10:39 AM -0800, Kei Nguyen via USRP-users , wrote:
> Thanks. After setting spp=600 and omit the DMA FIFO, it doesn't raise the 
> errors anymore and I can run the flowgraph without having to power cycle. I 
> think that is because the flow doesn't go through the host anymore. But it's 
> weird that after stopping the flowgraph the RX and TX lights are still on. 
> Why is that?
> By the way still I can't receive the relay signal in USRP 3.
>
> > On Fri, Mar 9, 2018 at 1:27 PM, Nick Foster  wrote:
> > > Are you using a custom FPGA image? What happens if you just omit the DMA 
> > > FIFO?
> > >
> > > Also, set a reasonable spp in your RX Radio block arguments -- 300 to 600 
> > > is a good start.
> > >
> > > Nick
> > >
> > > > On Fri, Mar 9, 2018 at 10:24 AM Kei Nguyen  
> > > > wrote:
> > > > > Thanks for the reply and sorry for not providing much information. My 
> > > > > case is that I want to do a relay transmission with the setup: USRP 1 
> > > > > transmits --> USRP 2 receives and retransmits with a shifted fc --> 
> > > > > USRP 3 receives.
> > > > > The problem is in USRP 2, as you pointed out in your post. I'm 
> > > > > testing on a simple flowgraph RX --> DDC --> DmaFIFO --> DUC 
> > > > > (frequency shifted by 5MHz) --> TX. I used your approach [1] in step 
> > > > > 1 of your tutorial (also did step 2 and 3) and rebuilt.
> > > > > At first the flowgraph runs without errors. The TX and RX lights were 
> > > > > on, so it seemed to transmit something. But in USRP 3 I didn't see 
> > > > > the relay signals (only the original signal that USRP1 transmits).
> > > > > Also, in the following runs, it raised the errors:
> > > > > [INFO] [UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800; 
> > > > > UHD_4.0.0.rfnoc-devel-409-gec9138eb]
> > > > > [INFO] [X300] X300 initialization sequence...
> > > > > [INFO] [X300] Determining maximum frame size...
> > > > > [INFO] [X300] Maximum frame size: 1472 bytes.
> > > > > [INFO] [X300] Setup basic communication...
> > > > > [INFO] [X300] Loading values from EEPROM...
> > > > > [INFO] [X300] Setup RF frontend clocking...
> > > > > [INFO] [X300] Radio 1x clock:200
> > > > > [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 0...
> > > > > [INFO] [RFNOC] pass (Throughput: 1302.9MB/s)
> > > > > [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 1...
> > > > > [INFO] [RFNOC] pass (Throughput: 1293.6MB/s)
> > > > > [INFO] [RFNOC RADIO] Register loopback test passed
> > > > > [INFO] [RFNOC RADIO] Register loopback test passed
> > > > > [INFO] [RFNOC RADIO] Register loopback test passed
> > > > > [INFO] [RFNOC RADIO] Register loopback test passed
> > > > > [INFO] [CORES] Performing timer loopback test...
> > > > > [INFO] [CORES] Timer loopback test passed
> > > > > [INFO] [CORES] Performing timer loopback test...
> > > > > [INFO] [CORES] Timer loopback test passed
> > > > > [INFO] [RFNOC] Assuming max packet size for 0/DDC_0
> > > > > [INFO] [RFNOC] Assuming max packet size for 0/DmaFIFO_0
> > > > > [INFO] [RFNOC] Assuming max packet size for 0/DUC_0
> > > > > [INFO] [RFNOC] Assuming max packet size for 0/Radio_0
> > > > > kei@kei-Precision-T7610:~/test_rfnoc$ ./relay.py
> > > > > [INFO] [UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800; 
> > > > > UHD_4.0.0.rfnoc-devel-409-gec9138eb]
> > > > > [INFO] [X300] X300 initialization sequence...
> > > > > [INFO] [X300] Determining maximum frame size...
> > > > > [INFO] [X300] Maximum frame size: 1472 bytes.
> > > > > [INFO] [X300] Setup basic communication...
> > > > > [INFO] [X300] Loading values from EEPROM...
> > > > > [INFO] [X300] Setup RF frontend clocking...
> > > > > [INFO] [X300] Radio 1x clock:200
> > > > > [ERROR] [UHD] Exception caught in safe-call.
> > > > >   in virtual ctrl_iface_impl::~ctrl_iface_impl()
> > > > >   at /home/kei/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
> > > > > this->peek32(0); -> EnvironmentError: IOError: Block ctrl 
> > > > > (CE_00_Port_30) packet parse error - EnvironmentError: IOError: 
> > > > > Expected packet index: 3  Received index: 4
> > > > > Traceback (most recent call last):
> > > > >   File "./relay.py", line 291, in 
> > > > >     main()
> > > > >   File "./relay.py", line 279, in main
> > > > >     tb = top_block_cls(freq=options.freq)
> > > > >   File "./relay.py", line 72, in __init__
> > > > >     self.device3 = device3 = ettus.device3(uhd.device_addr_t( 
> > > > > ",".join(('type=x300', "")) ))
> > > > >   File 
> > > > > "/home/kei/rfnoc/lib/python2.7/dist-packages/ettus/ettus_swig.py", 
> > > > > line 1610, in make
> > > > >     return _ettus_swig.device3_m

Re: [USRP-users] GRC + RFNoC + Radio Loopback

The lights are on because the device isn't instructed to stop streaming on
program stop, and it will continue loopback operation after the host has
closed the program. You can manually issue a stream command to stop the
stream before program stop if you want to change this behavior.

Kei, why would the flow go through the host at all in the example you
initially posted? The DMA FIFO exists on the FPGA.

Sam, the headers don't have to be modified in the FPGA if UHD instructs the
RX Radio to omit timestamps.

Nick

On Fri, Mar 9, 2018 at 10:57 AM Samuel Prager  wrote:

> Hello,
>
> I have had this issue and may be able to help. I believe that is because
> the rx packet headers need to be modified before the radio will transmit
> them. I would suggest looking at the siggen block and making a new ‘relay’
> noc block between the rx and tx in the fpga that modifies headers
> appropriately. I would guess that the lights are on because you have filled
> up all fifos.
>
> Sam
>
>
> On Mar 9, 2018, 10:39 AM -0800, Kei Nguyen via USRP-users , wrote:
>
> Thanks. After setting spp=600 and omit the DMA FIFO, it doesn't raise the
> errors anymore and I can run the flowgraph without having to power cycle. I
> think that is because the flow doesn't go through the host anymore. But
> it's weird that after stopping the flowgraph the RX and TX lights are still
> on. Why is that?
> By the way still I can't receive the relay signal in USRP 3.
>
> On Fri, Mar 9, 2018 at 1:27 PM, Nick Foster  wrote:
>
>> Are you using a custom FPGA image? What happens if you just omit the DMA
>> FIFO?
>>
>> Also, set a reasonable spp in your RX Radio block arguments -- 300 to 600
>> is a good start.
>>
>> Nick
>>
>> On Fri, Mar 9, 2018 at 10:24 AM Kei Nguyen 
>> wrote:
>>
>>> Thanks for the reply and sorry for not providing much information. My
>>> case is that I want to do a relay transmission with the setup: USRP 1
>>> transmits --> USRP 2 receives and retransmits with a shifted fc --> USRP 3
>>> receives.
>>> The problem is in USRP 2, as you pointed out in your post. I'm testing
>>> on a simple flowgraph RX --> DDC --> DmaFIFO --> DUC (frequency shifted by
>>> 5MHz) --> TX. I used your approach [1] in step 1 of your tutorial (also did
>>> step 2 and 3) and rebuilt.
>>> At first the flowgraph runs without errors. The TX and RX lights were
>>> on, so it seemed to transmit something. But in USRP 3 I didn't see the
>>> relay signals (only the original signal that USRP1 transmits).
>>> Also, in the following runs, it raised the errors:
>>> [INFO] [UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800;
>>> UHD_4.0.0.rfnoc-devel-409-gec9138eb]
>>> [INFO] [X300] X300 initialization sequence...
>>> [INFO] [X300] Determining maximum frame size...
>>> [INFO] [X300] Maximum frame size: 1472 bytes.
>>> [INFO] [X300] Setup basic communication...
>>> [INFO] [X300] Loading values from EEPROM...
>>> [INFO] [X300] Setup RF frontend clocking...
>>> [INFO] [X300] Radio 1x clock:200
>>> [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 0...
>>> [INFO] [RFNOC] pass (Throughput: 1302.9MB/s)
>>> [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 1...
>>> [INFO] [RFNOC] pass (Throughput: 1293.6MB/s)
>>> [INFO] [RFNOC RADIO] Register loopback test passed
>>> [INFO] [RFNOC RADIO] Register loopback test passed
>>> [INFO] [RFNOC RADIO] Register loopback test passed
>>> [INFO] [RFNOC RADIO] Register loopback test passed
>>> [INFO] [CORES] Performing timer loopback test...
>>> [INFO] [CORES] Timer loopback test passed
>>> [INFO] [CORES] Performing timer loopback test...
>>> [INFO] [CORES] Timer loopback test passed
>>> [INFO] [RFNOC] Assuming max packet size for 0/DDC_0
>>> [INFO] [RFNOC] Assuming max packet size for 0/DmaFIFO_0
>>> [INFO] [RFNOC] Assuming max packet size for 0/DUC_0
>>> [INFO] [RFNOC] Assuming max packet size for 0/Radio_0
>>> kei@kei-Precision-T7610:~/test_rfnoc$ ./relay.py
>>> [INFO] [UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800;
>>> UHD_4.0.0.rfnoc-devel-409-gec9138eb]
>>> [INFO] [X300] X300 initialization sequence...
>>> [INFO] [X300] Determining maximum frame size...
>>> [INFO] [X300] Maximum frame size: 1472 bytes.
>>> [INFO] [X300] Setup basic communication...
>>> [INFO] [X300] Loading values from EEPROM...
>>> [INFO] [X300] Setup RF frontend clocking...
>>> [INFO] [X300] Radio 1x clock:200
>>> [ERROR] [UHD] Exception caught in safe-call.
>>>   in virtual ctrl_iface_impl::~ctrl_iface_impl()
>>>   at /home/kei/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
>>> this->peek32(0); -> EnvironmentError: IOError: Block ctrl
>>> (CE_00_Port_30) packet parse error - EnvironmentError: IOError: Expected
>>> packet index: 3  Received index: 4
>>> Traceback (most recent call last):
>>>   File "./relay.py", line 291, in 
>>> main()
>>>   File "./relay.py", line 279, in main
>>> tb = top_block_cls(freq=options.freq)
>>>   File "./relay.py", line 72, in __init__
>>> self.device3 = device3 = ettus.device3(uhd.device_addr_t(
>>> ",".join(('type=x300'

Re: [USRP-users] TwinRx Channel Alignment

On 03/09/2018 03:23 AM, Derek Kozel via USRP-users wrote:

Hello,

Yes, that is the purpose of the set_time_next_pps function. When
combined with common 10 MHz and 1 PPS references this allows for
stable time synchronization of 1 sample clock cycle, 5 ns at 200 MS/s.
I recommend reading through the examples which show using all these
commands and others related to streaming multiple channels.

https://github.com/EttusResearch/uhd/tree/maint/host/examples

The manual also covers these topics.
http://files.ettus.com/manual/page_sync.html

Derek

There's also, of course:

https://kb.ettus.com/Synchronization_and_MIMO_Capability_with_USRP_Devices

On Thu, Mar 8, 2018 at 11:02 PM, Zhongyuan Zhao > wrote:

Hi Derek,

If USRPs A & B clocked by an Octoclock, are connected to the same
host, I want calibrate the counter values from USRPs A and B. How
can I do it? Is this function supported by UHD? If not, could I
update the counter values in the FPGA Radio blocks? or I can only
keep an calibration table of counter value offsets on my host?

Thanks!

Zhongyuan Zhao

PhD Candidate,
Department of Computer Science & Engineering,
University of Nebraska-Lincoln
Office Hour: WF 9:30-10:00am, Avery Hall 12,
Suite 117, Schorr Center,
Lincoln, Nebraska 68588-0115

On Thu, Mar 8, 2018 at 4:42 PM, Derek Kozel mailto:derek.ko...@ettus.com>> wrote:

Hello,

The same commands are available in the GNU Radio environment
and I believe are exposed in the pre-release Python API branch.

The FPGA radio blocks contain a timekeeper which is a counter
which increments at the same rate as the master_clock_rate
which is the effective ADC/DAC sample rate. This allows for
commands to be executed with very fine temporal precision.

Regards,
Derek

On Thu, Mar 8, 2018 at 10:12 PM, Zhongyuan Zhao
mailto:zhz...@cse.unl.edu>> wrote:

Hi Derek,

I have two questions about the rx timed samples example,
1. is there python version for timed command?
2. Is the time stamp from the clock on USRP or on the host?

Thanks

Zhongyuan Zhao

PhD Candidate,
Department of Computer Science & Engineering,
University of Nebraska-Lincoln
Office Hour: WF 9:30-10:00am, Avery Hall 12,
Suite 117, Schorr Center,
Lincoln, Nebraska 68588-0115

On Thu, Mar 8, 2018 at 3:27 PM, Derek Kozel via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:

The stream command object has a field for a time spec
of when to start streaming and a boolean flag for
whether to make use of that time spec.
http://files.ettus.com/manual/structuhd_1_1stream__cmd__t.html

Here we can see it used in an rx example.

https://github.com/EttusResearch/uhd/blob/maint/host/examples/rx_timed_samples.cpp#L92-L93

Usually it is most practical to make a call to
get_time_now() and then add an offset from that time
which is returned. The minimum offset would be the
roundtrip command time, usually a few milliseconds.

Regards,
Derek

On Thu, Mar 8, 2018 at 9:03 PM, Andrew Thommesen
mailto:andrewjoh...@outlook.com>> wrote:

No, how do you do that?

Sent from Outlook

*From:* Derek Kozel mailto:derek.ko...@ettus.com>>
*Sent:* 08 March 2018 20:58:38
*To:* Andrew Thommesen
*Cc:* usrp-users
*Subject:* Re: [USRP-users] TwinRx Channel Alignment
Hello Andrew,

Are you starting the streaming with timed commands?

Regards,
Derek

On Mar 8, 2018 7:32 PM, "Andrew Thommesen via
USRP-users" mailto:usrp-users@lists.ettus.com>> wrote:

Hi all,

I have an x310 with a twinRx and would like to
process coherent, time aligned data within the
FPGA. However, the data is not currently time
aligned and there is an offset of ~400 samples
between the two channels.

The RFNoC radio block is configured to receive
data on b

Re: [USRP-users] GRC + RFNoC + Radio Loopback

2018-03-09 Thread Kei Nguyen via USRP-users

Sorry I mean the lights were on when I closed the program.
Thanks Sam for the suggestion I will try to take a look into it.

On Fri, Mar 9, 2018 at 2:02 PM, Nick Foster  wrote:

> The lights are on because the device isn't instructed to stop streaming on
> program stop, and it will continue loopback operation after the host has
> closed the program. You can manually issue a stream command to stop the
> stream before program stop if you want to change this behavior.
>
> Kei, why would the flow go through the host at all in the example you
> initially posted? The DMA FIFO exists on the FPGA.
>
> Sam, the headers don't have to be modified in the FPGA if UHD instructs
> the RX Radio to omit timestamps.
>
> Nick
>
> On Fri, Mar 9, 2018 at 10:57 AM Samuel Prager  wrote:
>
>> Hello,
>>
>> I have had this issue and may be able to help. I believe that is because
>> the rx packet headers need to be modified before the radio will transmit
>> them. I would suggest looking at the siggen block and making a new ‘relay’
>> noc block between the rx and tx in the fpga that modifies headers
>> appropriately. I would guess that the lights are on because you have filled
>> up all fifos.
>>
>> Sam
>>
>>
>> On Mar 9, 2018, 10:39 AM -0800, Kei Nguyen via USRP-users , wrote:
>>
>> Thanks. After setting spp=600 and omit the DMA FIFO, it doesn't raise the
>> errors anymore and I can run the flowgraph without having to power cycle. I
>> think that is because the flow doesn't go through the host anymore. But
>> it's weird that after stopping the flowgraph the RX and TX lights are still
>> on. Why is that?
>> By the way still I can't receive the relay signal in USRP 3.
>>
>> On Fri, Mar 9, 2018 at 1:27 PM, Nick Foster  wrote:
>>
>>> Are you using a custom FPGA image? What happens if you just omit the DMA
>>> FIFO?
>>>
>>> Also, set a reasonable spp in your RX Radio block arguments -- 300 to
>>> 600 is a good start.
>>>
>>> Nick
>>>
>>> On Fri, Mar 9, 2018 at 10:24 AM Kei Nguyen 
>>> wrote:
>>>
 Thanks for the reply and sorry for not providing much information. My
 case is that I want to do a relay transmission with the setup: USRP 1
 transmits --> USRP 2 receives and retransmits with a shifted fc --> USRP 3
 receives.
 The problem is in USRP 2, as you pointed out in your post. I'm testing
 on a simple flowgraph RX --> DDC --> DmaFIFO --> DUC (frequency shifted by
 5MHz) --> TX. I used your approach [1] in step 1 of your tutorial (also did
 step 2 and 3) and rebuilt.
 At first the flowgraph runs without errors. The TX and RX lights were
 on, so it seemed to transmit something. But in USRP 3 I didn't see the
 relay signals (only the original signal that USRP1 transmits).
 Also, in the following runs, it raised the errors:
 [INFO] [UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800;
 UHD_4.0.0.rfnoc-devel-409-gec9138eb]
 [INFO] [X300] X300 initialization sequence...
 [INFO] [X300] Determining maximum frame size...
 [INFO] [X300] Maximum frame size: 1472 bytes.
 [INFO] [X300] Setup basic communication...
 [INFO] [X300] Loading values from EEPROM...
 [INFO] [X300] Setup RF frontend clocking...
 [INFO] [X300] Radio 1x clock:200
 [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 0...
 [INFO] [RFNOC] pass (Throughput: 1302.9MB/s)
 [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 1...
 [INFO] [RFNOC] pass (Throughput: 1293.6MB/s)
 [INFO] [RFNOC RADIO] Register loopback test passed
 [INFO] [RFNOC RADIO] Register loopback test passed
 [INFO] [RFNOC RADIO] Register loopback test passed
 [INFO] [RFNOC RADIO] Register loopback test passed
 [INFO] [CORES] Performing timer loopback test...
 [INFO] [CORES] Timer loopback test passed
 [INFO] [CORES] Performing timer loopback test...
 [INFO] [CORES] Timer loopback test passed
 [INFO] [RFNOC] Assuming max packet size for 0/DDC_0
 [INFO] [RFNOC] Assuming max packet size for 0/DmaFIFO_0
 [INFO] [RFNOC] Assuming max packet size for 0/DUC_0
 [INFO] [RFNOC] Assuming max packet size for 0/Radio_0
 kei@kei-Precision-T7610:~/test_rfnoc$ ./relay.py
 [INFO] [UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800;
 UHD_4.0.0.rfnoc-devel-409-gec9138eb]
 [INFO] [X300] X300 initialization sequence...
 [INFO] [X300] Determining maximum frame size...
 [INFO] [X300] Maximum frame size: 1472 bytes.
 [INFO] [X300] Setup basic communication...
 [INFO] [X300] Loading values from EEPROM...
 [INFO] [X300] Setup RF frontend clocking...
 [INFO] [X300] Radio 1x clock:200
 [ERROR] [UHD] Exception caught in safe-call.
   in virtual ctrl_iface_impl::~ctrl_iface_impl()
   at /home/kei/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
 this->peek32(0); -> EnvironmentError: IOError: Block ctrl
 (CE_00_Port_30) packet parse error - EnvironmentError: IOError: Expected
 packet index: 3  Received index: 4
 Traceback (most recent c

Re: [USRP-users] E312 Loopback Path Delay Changes when FPGA image is reloaded

On 03/09/2018 01:22 PM, Nick Foster wrote:
One thing that struck me: I don't think you should have to disable the
streamer to switch between cal and radio channels. Just for
experiment's sake, try leaving both channels active in the streamer.
You can pull samples from both channels in your recv() command, and
just use the channel you're interested in. Does doing this affect the
result?

Nick
One thing that I recall--the E3XX has two separate TOD clocks, which
MUST be synchronized to get synchronized streaming, even though this is the

same physical radio.

Do a set_time_unknown_pps() on both channels, and then start streaming
at some future point--does that help?

On Fri, Mar 9, 2018 at 10:13 AM Samuel Prager > wrote:

Hey Nick,

No prob blew at all. The flag /“no_reload_fpga”/ seems to work for
that. The bigger problem is that each time the fpga image is
loaded on the e3xx, the relative path delays between the RXA and
RXB channels changes randomly as seen by the sample group jumps in
the image I originally attached. The random LO phase is measured
and removed, so there is something else happening in this strange
case.

If anyone has any ideas as to what could be causing this please
help! The phase stability of the E312 is amazing within the same
fpga image cycle but these relatively large jumps after reload/
power cycle are a deal breaker for some applications!

Thanks

Sam

On Mar 9, 2018, 9:19 AM -0800, Nick Foster via USRP-users
mailto:usrp-users@lists.ettus.com>>,
wrote:

Sam,

Sorry I haven't gotten back -- it sounds like you're doing
everything right. The usual quick fixes probably don't apply
here. I haven't had time to look more in depth into it, or to try
to replicate it on my own hardware.

Marcus is right -- the E3xx uses an idle image in order to reduce
power consumption when the radio is inactive. I'm not sure if
there's a flag that will tell UHD not to load the idle image.

Nick

On Thu, Mar 8, 2018 at 9:30 PM Marcus D. Leech via USRP-users
mailto:usrp-users@lists.ettus.com>>
wrote:

On 03/09/2018 12:11 AM, Samuel Prager via USRP-users wrote:

Still looking for more info on this problem.

I have the exact same RfNoC block/software program running
on an X300 and see no such jumps or otherwise unexpected
behavior.

I have attempted to isolate this issue on the E312 by
creating the device3 with the */“no_reload_fpga”/* flag.
(Appropriate image is loaded before hand with the
uhd_usrp_image_loader. Running my program the first time
works as expected, but if I kill the program and restart, I
get this error:

/“AssertionError: zf_peek32(ctrl_base+ARBITER_RB_ADDR_SPACE)
> 0 in virtual void e300_fifo_mb::release()"/

The last few lines in the Uhd log file are:

/e300_impl.cpp:639,1,E300,[E300] Setting up dest map for
host ep 0 to be stream 0

device3_impl.cpp:131,0, DEVICE3, Setting up NoC-Shell
Control for port #0 (SID; 00:00>02:10)
device3_impl.cpp:139,0,DEVICE3, OK
davice3_impl.cpp:141,0, DEVICE3, Port 16: found NoC-Block
with ID 12AD1000.
e300_impl.cpp:639,1,E300, [E300] Setting up dest map for
host ep 1 to be stream 1

device3_impl.cpp:160,0,DEVICE3, Setting up NoC Shell port
for #1 (SID: 00:01>02:11)/

Shouldn’t the E312 be able to operate without needing to
reload the FPGA image each time? Has this been tested? I
would really appreciate any hints or pointers into why this
is happening.

Thank you,

Sam

The E3xx run an "idle" image when the device is not being
used. I cannot remember the reason for that, TBH.

___
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

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com&d=DwICAg&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=opIuWAKmywF059tAs2i3Pg&m=HkJbIenCP1t5oGgIxFFvHftFEabvbCk9VlUuv6EBHqA&s=HutNULVtirv0JuQ4R8HiR34nBs82dDVsc3zQccm3BTU&e=

___
USRP-users mailing list
USRP-users@lists.ettus

Re: [USRP-users] GRC + RFNoC + Radio Loopback

If the lights are on, the device is streaming, guaranteed. At this point,
make sure your frequencies, gains, and antenna selections are correct.

Nick

On Fri, Mar 9, 2018 at 11:19 AM Kei Nguyen 
wrote:

> Sorry I mean the lights were on when I closed the program.
> Thanks Sam for the suggestion I will try to take a look into it.
>
> On Fri, Mar 9, 2018 at 2:02 PM, Nick Foster  wrote:
>
>> The lights are on because the device isn't instructed to stop streaming
>> on program stop, and it will continue loopback operation after the host has
>> closed the program. You can manually issue a stream command to stop the
>> stream before program stop if you want to change this behavior.
>>
>> Kei, why would the flow go through the host at all in the example you
>> initially posted? The DMA FIFO exists on the FPGA.
>>
>> Sam, the headers don't have to be modified in the FPGA if UHD instructs
>> the RX Radio to omit timestamps.
>>
>> Nick
>>
>> On Fri, Mar 9, 2018 at 10:57 AM Samuel Prager  wrote:
>>
>>> Hello,
>>>
>>> I have had this issue and may be able to help. I believe that is because
>>> the rx packet headers need to be modified before the radio will transmit
>>> them. I would suggest looking at the siggen block and making a new ‘relay’
>>> noc block between the rx and tx in the fpga that modifies headers
>>> appropriately. I would guess that the lights are on because you have filled
>>> up all fifos.
>>>
>>> Sam
>>>
>>>
>>> On Mar 9, 2018, 10:39 AM -0800, Kei Nguyen via USRP-users , wrote:
>>>
>>> Thanks. After setting spp=600 and omit the DMA FIFO, it doesn't raise
>>> the errors anymore and I can run the flowgraph without having to power
>>> cycle. I think that is because the flow doesn't go through the host
>>> anymore. But it's weird that after stopping the flowgraph the RX and TX
>>> lights are still on. Why is that?
>>> By the way still I can't receive the relay signal in USRP 3.
>>>
>>> On Fri, Mar 9, 2018 at 1:27 PM, Nick Foster 
>>> wrote:
>>>
 Are you using a custom FPGA image? What happens if you just omit the
 DMA FIFO?

 Also, set a reasonable spp in your RX Radio block arguments -- 300 to
 600 is a good start.

 Nick

 On Fri, Mar 9, 2018 at 10:24 AM Kei Nguyen 
 wrote:

> Thanks for the reply and sorry for not providing much information. My
> case is that I want to do a relay transmission with the setup: USRP 1
> transmits --> USRP 2 receives and retransmits with a shifted fc --> USRP 3
> receives.
> The problem is in USRP 2, as you pointed out in your post. I'm testing
> on a simple flowgraph RX --> DDC --> DmaFIFO --> DUC (frequency shifted by
> 5MHz) --> TX. I used your approach [1] in step 1 of your tutorial (also 
> did
> step 2 and 3) and rebuilt.
> At first the flowgraph runs without errors. The TX and RX lights were
> on, so it seemed to transmit something. But in USRP 3 I didn't see the
> relay signals (only the original signal that USRP1 transmits).
> Also, in the following runs, it raised the errors:
> [INFO] [UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_4.0.0.rfnoc-devel-409-gec9138eb]
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Determining maximum frame size...
> [INFO] [X300] Maximum frame size: 1472 bytes.
> [INFO] [X300] Setup basic communication...
> [INFO] [X300] Loading values from EEPROM...
> [INFO] [X300] Setup RF frontend clocking...
> [INFO] [X300] Radio 1x clock:200
> [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 0...
> [INFO] [RFNOC] pass (Throughput: 1302.9MB/s)
> [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 1...
> [INFO] [RFNOC] pass (Throughput: 1293.6MB/s)
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [CORES] Performing timer loopback test...
> [INFO] [CORES] Timer loopback test passed
> [INFO] [CORES] Performing timer loopback test...
> [INFO] [CORES] Timer loopback test passed
> [INFO] [RFNOC] Assuming max packet size for 0/DDC_0
> [INFO] [RFNOC] Assuming max packet size for 0/DmaFIFO_0
> [INFO] [RFNOC] Assuming max packet size for 0/DUC_0
> [INFO] [RFNOC] Assuming max packet size for 0/Radio_0
> kei@kei-Precision-T7610:~/test_rfnoc$ ./relay.py
> [INFO] [UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_4.0.0.rfnoc-devel-409-gec9138eb]
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Determining maximum frame size...
> [INFO] [X300] Maximum frame size: 1472 bytes.
> [INFO] [X300] Setup basic communication...
> [INFO] [X300] Loading values from EEPROM...
> [INFO] [X300] Setup RF frontend clocking...
> [INFO] [X300] Radio 1x clock:200
> [ERROR] [UHD] Exception caught in safe-call.
>   in

[USRP-users] The daughterboard manager encountered a recoverable error in init.-USRP2

2018-03-09 Thread Anouar Chahbouni via USRP-users


Hello,


I am using the USRP2/N-Series and trying to receive a simply signal with 
Gnuradio.

I have this error but I don't know how to resolve it.
::
[32;1m[INFO] [UHD] [39;0mlinux; GNU C++ version 5.4.0 20160609; 
Boost_105800; UHD_3.11.0.0-0-g13c32cef

[32;1m[INFO] [USRP2] [39;0mOpening a USRP2/N-Series device...
[32;1m[INFO] [USRP2] [39;0mCurrent recv frame size: 1472 bytes
[32;1m[INFO] [USRP2] [39;0mCurrent send frame size: 1472 bytes
[31;0m[ERROR] [DBMGR] [39;0mThe daughterboard manager encountered a 
recoverable error in init.

Loading the "unknown" daughterboard implementations to continue.
The daughterboard cannot operate until this error is resolved.
LookupError: KeyError: key "0" not found in dict(i, 
N14adf4360_regs_t17prescaler_value_tE)
[33;1m[WARNING] [UHD] [39;0mUnable 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


So,

I type on the terminal the *uhd_usrp_probe*command, I get this with the same 
error/:
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
UHD_3.11.0.0-0-g13c32cef [INFO] [USRP2] Opening a USRP2/N-Series 
device... [INFO] [USRP2] Current recv frame size: 1472 bytes [INFO] 
[USRP2] Current send frame size: 1472 bytes [ERROR] [DBMGR] The 
daughterboard manager encountered a recoverable error in init. Loading 
the "unknown" daughterboard implementations to continue. The 
daughterboard cannot operate until this error is resolved. LookupError: 
KeyError: key "0" not found in dict(i, 
N14adf4360_regs_t17prescaler_value_tE) [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   
_  / |   Device: 
USRP2 / N-Series Device | 
_ |    / |   |   
Mboard: USRP2 r4 |   |   hardware: 1024 |   |   mac-addr: XXX |   |   
ip-addr: XXX |   |   subnet: XXX |   |   gateway: XXX |   |   gpsdo: 
none |   |   serial: 1071 |   |   name: XX |   |   FW Version: 12.3 |   
|   FPGA Version: 10.0 |   | |   |   Time sources:  none, external, 
_external_, mimo |   |   Clock sources: internal, external, mimo |   |   
Sensors: mimo_locked, ref_locked |   | 
_ |   |    / |   |   
|   RX DSP: 0 |   |   | |   |   |   Freq range: -50.000 to 50.000 
MHz |   | _ |   
|    / |   |   |   RX DSP: 1 |   |   | |   |   |   Freq range: 
-50.000 to 50.000 MHz |   | 
_ |   |    / |   |   
|   RX Dboard: A |   |   |   ID: RFX2400 (0x0027) |   |   | 
_ |   |   |    / |   
|   |   |   RX Frontend: 0 |   |   |   |   Name: Unknown (0x) - 
0 |   |   |   |   Antennas: |   |   |   |   Sensors: |   |   |   |   
Freq range: 0.000 to 0.000 MHz |   |   |   |   Gain Elements: None |   
|   |   |   Bandwidth range: 0.0 to 0.0 step 0.0 Hz |   |   |   |   
Connection Type: IQ |   |   |   |   Uses LO offset: No |   |   | 
_ |   |   |    / |   
|   |   |   RX Codec: A |   |   |   |   Name: ltc2284 |   |   |   
|   Gain Elements: None |   | 
_ |   |    / |   |   
|   TX DSP: 0 |   |   | |   |   |   Freq range: -50.000 to 50.000 
MHz |   | _ |   
|    / |   |   |   TX Dboard: A |   |   |   ID: RFX2400 (0x002b) |   
|   | _ |   |   
|    / |   |   |   |   TX Frontend: 0 |   |   |   |   Name: Unknown 
(0x) - 0 |   |   |   |   Antennas: |   |   |   |   Sensors: |   |   
|   |   Freq range: 0.000 to 0.000 MHz |   |   |   |   Gain Elements: 
None |   |   |   |   Bandwidth range: 0.0 to 0.0 step 0.0 Hz |   |   |   
|   Connection Type: IQ |   |   |   |   Uses LO offset: No |   |   | 
_ |   |   |    / |   
|   |   |   TX Codec: A |   |   |   |   Name: ad9777 |   |   |   |   
Gain Elements: None [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.
EnvironmentError: OSError: error in pthread_setschedparam [ERROR] [UHD] 
Exception caught in safe-call.   in virtual 
usrp2_fifo_ctrl_impl::~usrp2_fifo_ctrl_impl()   at 
/usr/local/src/uhd/host/lib/usrp/usrp2/usrp2_fifo_ctrl.cpp:54 
this->peek32(0); -> RuntimeError: fifo ctrl timed out looking for acks.


Itype on the terminal the *uhd_conf

Re: [USRP-users] How to change B210 10Mz from Output to Input?

2018-03-09 Thread Marcus Müller via USRP-users

Dear Sailor Jerry,

I'm not sure I'm following here: The 10 MHz connector is hardware-wise
connected only to inputs, not to anything that can output anything;
compare the schematic[1] on page 1. So, I'm pretty certain your device
can't be condigured to have the 10 MHz connector be an output for
anything.

Can you maybe describe the problem you're having?

Best regards,
Marcus

[1] https://files.ettus.com/schematics/b200/b210.pdf
On Fri, 2018-03-09 at 23:51 +, Sailor Jerry via USRP-users wrote:
> I inherited the B210 board that has the 10 MHz connector configured
> as an output. I wonder if anyone is aware of this configuration and
> if it's possible to reconfigure it to accept the external 10 MHz
> input. 
> 
> My current plan is simply remove GPSDO and hope for the best. 
> 
> Attached are two pictures of my board. One is with GPSDO inserted and
> another one with GPSDO removed. 
> 
> Thanks a lot!
> 
> 
> 
> ___
> 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] How to change B210 10Mz from Output to Input?

HI Marcus, I see your point and also saw the schematic. The previous owner
told me that this particular board was modified to have 10 MHz be brought
out to the outside connector. I did verify it with the scope and indeed saw
the 10 MHz coming out. I don't know if it's one of the standard factory
options or just some custom modifications (the board has Olifantasia label
on it).  Will take a closer look at pins 3 and 1 of U103 as you suggest.
If they are bridged indeed then I guess simple removal of GPSDO would do
the trick.

On Fri, Mar 9, 2018 at 4:10 PM Marcus Müller 
wrote:

> Dear Sailor Jerry,
>
> I'm not sure I'm following here: The 10 MHz connector is hardware-wise
> connected only to inputs, not to anything that can output anything;
> compare the schematic[1] on page 1. So, I'm pretty certain your device
> can't be condigured to have the 10 MHz connector be an output for
> anything.
>
> Can you maybe describe the problem you're having?
>
> Best regards,
> Marcus
>
> [1] https://files.ettus.com/schematics/b200/b210.pdf
> On Fri, 2018-03-09 at 23:51 +, Sailor Jerry via USRP-users wrote:
> > I inherited the B210 board that has the 10 MHz connector configured
> > as an output. I wonder if anyone is aware of this configuration and
> > if it's possible to reconfigure it to accept the external 10 MHz
> > input.
> >
> > My current plan is simply remove GPSDO and hope for the best.
> >
> > Attached are two pictures of my board. One is with GPSDO inserted and
> > another one with GPSDO removed.
> >
> > Thanks a lot!
> >
> >
> >
> > ___
> > 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] How to change B210 10Mz from Output to Input?

On 03/09/2018 07:22 PM, Sailor Jerry via USRP-users wrote:
HI Marcus, I see your point and also saw the schematic. The previous 
owner told me that this particular board was modified to have 10 MHz 
be brought out to the outside connector. I did verify it with the 
scope and indeed saw the 10 MHz coming out. I don't know if it's one 
of the standard factory options or just some custom modifications (the 
board has Olifantasia label on it).  Will take a closer look at pins 3 
and 1 of U103 as you suggest.  If they are bridged indeed then I guess 
simple removal of GPSDO would do the trick.

That is NOT a factory-standard option.

On Fri, Mar 9, 2018 at 4:10 PM Marcus Müller > wrote:

Dear Sailor Jerry,

I'm not sure I'm following here: The 10 MHz connector is hardware-wise
connected only to inputs, not to anything that can output anything;
compare the schematic[1] on page 1. So, I'm pretty certain your device
can't be condigured to have the 10 MHz connector be an output for
anything.

Can you maybe describe the problem you're having?

Best regards,
Marcus

[1] https://files.ettus.com/schematics/b200/b210.pdf
On Fri, 2018-03-09 at 23:51 +, Sailor Jerry via USRP-users wrote:
> I inherited the B210 board that has the 10 MHz connector configured
> as an output. I wonder if anyone is aware of this configuration and
> if it's possible to reconfigure it to accept the external 10 MHz
> input.
>
> My current plan is simply remove GPSDO and hope for the best.
>
> Attached are two pictures of my board. One is with GPSDO
inserted and
> another one with GPSDO removed.
>
> Thanks a lot!
>
>
>
> ___
> 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 mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] How to change B210 10Mz from Output to Input?

It's a slick mod though. See the zero-ohm resistor bridging U103 pins 1 and
3? Remove it, and you'll return the B210 to factory standard.

Assuming no other modifications have also been made.  =)

Nick

On Fri, Mar 9, 2018 at 4:31 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 03/09/2018 07:22 PM, Sailor Jerry via USRP-users wrote:
>
> HI Marcus, I see your point and also saw the schematic. The previous owner
> told me that this particular board was modified to have 10 MHz be brought
> out to the outside connector. I did verify it with the scope and indeed saw
> the 10 MHz coming out. I don't know if it's one of the standard factory
> options or just some custom modifications (the board has Olifantasia label
> on it).  Will take a closer look at pins 3 and 1 of U103 as you suggest.
> If they are bridged indeed then I guess simple removal of GPSDO would do
> the trick.
>
>
> That is NOT a factory-standard option.
>
>
>
>
> On Fri, Mar 9, 2018 at 4:10 PM Marcus Müller 
> wrote:
>
>> Dear Sailor Jerry,
>>
>> I'm not sure I'm following here: The 10 MHz connector is hardware-wise
>> connected only to inputs, not to anything that can output anything;
>> compare the schematic[1] on page 1. So, I'm pretty certain your device
>> can't be condigured to have the 10 MHz connector be an output for
>> anything.
>>
>> Can you maybe describe the problem you're having?
>>
>> Best regards,
>> Marcus
>>
>> [1] https://files.ettus.com/schematics/b200/b210.pdf
>> On Fri, 2018-03-09 at 23:51 +, Sailor Jerry via USRP-users wrote:
>> > I inherited the B210 board that has the 10 MHz connector configured
>> > as an output. I wonder if anyone is aware of this configuration and
>> > if it's possible to reconfigure it to accept the external 10 MHz
>> > input.
>> >
>> > My current plan is simply remove GPSDO and hope for the best.
>> >
>> > Attached are two pictures of my board. One is with GPSDO inserted and
>> > another one with GPSDO removed.
>> >
>> > Thanks a lot!
>> >
>> >
>> >
>> > ___
>> > USRP-users mailing list
>> > USRP-users@lists.ettus.com
>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://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 mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] How to change B210 10Mz from Output to Input?

On 03/09/2018 08:11 PM, Nick Foster wrote:
It's a slick mod though. See the zero-ohm resistor bridging U103 pins 
1 and 3? Remove it, and you'll return the B210 to factory standard.

Assuming no other modifications have also been made.  =)

Nick

Your eyes are much better than mine

On Fri, Mar 9, 2018 at 4:31 PM Marcus D. Leech via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

On 03/09/2018 07:22 PM, Sailor Jerry via USRP-users wrote:

HI Marcus, I see your point and also saw the schematic. The
previous owner told me that this particular board was modified to
have 10 MHz be brought out to the outside connector. I did verify
it with the scope and indeed saw the 10 MHz coming out. I don't
know if it's one of the standard factory options or just some
custom modifications (the board has Olifantasia label on it). 
Will take a closer look at pins 3 and 1 of U103 as you suggest. 
If they are bridged indeed then I guess simple removal of GPSDO

would do the trick.

That is NOT a factory-standard option.

On Fri, Mar 9, 2018 at 4:10 PM Marcus Müller
mailto:marcus.muel...@ettus.com>> wrote:

Dear Sailor Jerry,

I'm not sure I'm following here: The 10 MHz connector is
hardware-wise
connected only to inputs, not to anything that can output
anything;
compare the schematic[1] on page 1. So, I'm pretty certain
your device
can't be condigured to have the 10 MHz connector be an output for
anything.

Can you maybe describe the problem you're having?

Best regards,
Marcus

[1] https://files.ettus.com/schematics/b200/b210.pdf
On Fri, 2018-03-09 at 23:51 +, Sailor Jerry via
USRP-users wrote:
> I inherited the B210 board that has the 10 MHz connector
configured
> as an output. I wonder if anyone is aware of this
configuration and
> if it's possible to reconfigure it to accept the external
10 MHz
> input.
>
> My current plan is simply remove GPSDO and hope for the best.
>
> Attached are two pictures of my board. One is with GPSDO
inserted and
> another one with GPSDO removed.
>
> Thanks a lot!
>
>
>
> ___
> 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 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] How to change B210 10Mz from Output to Input?

Would be happy to restore it to original condition :-)

I'm using the uhd_rx_cfile to capture the data. How do I control U103 from
this app? I don't see any command line arguments for that? Do I need to
rebuild it?



On Fri, Mar 9, 2018 at 8:08 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 03/09/2018 08:11 PM, Nick Foster wrote:
>
> It's a slick mod though. See the zero-ohm resistor bridging U103 pins 1
> and 3? Remove it, and you'll return the B210 to factory standard.
>
> Assuming no other modifications have also been made.  =)
>
> Nick
>
> Your eyes are much better than mine
>
>
>
> On Fri, Mar 9, 2018 at 4:31 PM Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 03/09/2018 07:22 PM, Sailor Jerry via USRP-users wrote:
>>
>> HI Marcus, I see your point and also saw the schematic. The previous
>> owner told me that this particular board was modified to have 10 MHz be
>> brought out to the outside connector. I did verify it with the scope and
>> indeed saw the 10 MHz coming out. I don't know if it's one of the standard
>> factory options or just some custom modifications (the board has
>> Olifantasia label on it).  Will take a closer look at pins 3 and 1 of U103
>> as you suggest.  If they are bridged indeed then I guess simple removal of
>> GPSDO would do the trick.
>>
>>
>> That is NOT a factory-standard option.
>>
>>
>>
>>
>> On Fri, Mar 9, 2018 at 4:10 PM Marcus Müller 
>> wrote:
>>
>>> Dear Sailor Jerry,
>>>
>>> I'm not sure I'm following here: The 10 MHz connector is hardware-wise
>>> connected only to inputs, not to anything that can output anything;
>>> compare the schematic[1] on page 1. So, I'm pretty certain your device
>>> can't be condigured to have the 10 MHz connector be an output for
>>> anything.
>>>
>>> Can you maybe describe the problem you're having?
>>>
>>> Best regards,
>>> Marcus
>>>
>>> [1] https://files.ettus.com/schematics/b200/b210.pdf
>>> On Fri, 2018-03-09 at 23:51 +, Sailor Jerry via USRP-users wrote:
>>> > I inherited the B210 board that has the 10 MHz connector configured
>>> > as an output. I wonder if anyone is aware of this configuration and
>>> > if it's possible to reconfigure it to accept the external 10 MHz
>>> > input.
>>> >
>>> > My current plan is simply remove GPSDO and hope for the best.
>>> >
>>> > Attached are two pictures of my board. One is with GPSDO inserted and
>>> > another one with GPSDO removed.
>>> >
>>> > Thanks a lot!
>>> >
>>> >
>>> >
>>> > ___
>>> > USRP-users mailing list
>>> > USRP-users@lists.ettus.com
>>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>>
>> ___
>> USRP-users mailing 
>> listUSRP-users@lists.ettus.comhttp://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 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] How to change B210 10Mz from Output to Input?

On 03/09/2018 11:25 PM, Sailor Jerry wrote:

Would be happy to restore it to original condition :-)

I'm using the uhd_rx_cfile to capture the data. How do I control U103 
from this app? I don't see any command line arguments for that? Do I 
need to rebuild it?
You'd have to add that, inserting a call to set_clock_source() at an 
appropriate place.

The example apps (and this is one) don't necessarily expose all 
available features.

On Fri, Mar 9, 2018 at 8:08 PM Marcus D. Leech via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

On 03/09/2018 08:11 PM, Nick Foster wrote:

It's a slick mod though. See the zero-ohm resistor bridging U103
pins 1 and 3? Remove it, and you'll return the B210 to factory
standard.

Assuming no other modifications have also been made. =)

Nick

Your eyes are much better than mine

On Fri, Mar 9, 2018 at 4:31 PM Marcus D. Leech via USRP-users
mailto:usrp-users@lists.ettus.com>>
wrote:

On 03/09/2018 07:22 PM, Sailor Jerry via USRP-users wrote:

HI Marcus, I see your point and also saw the schematic. The
previous owner told me that this particular board was
modified to have 10 MHz be brought out to the outside
connector. I did verify it with the scope and indeed saw the
10 MHz coming out. I don't know if it's one of the standard
factory options or just some custom modifications (the board
has Olifantasia label on it).  Will take a closer look at
pins 3 and 1 of U103 as you suggest.  If they are bridged
indeed then I guess simple removal of GPSDO would do the trick.

That is NOT a factory-standard option.

On Fri, Mar 9, 2018 at 4:10 PM Marcus Müller
mailto:marcus.muel...@ettus.com>>
wrote:

Dear Sailor Jerry,

I'm not sure I'm following here: The 10 MHz connector is
hardware-wise
connected only to inputs, not to anything that can
output anything;
compare the schematic[1] on page 1. So, I'm pretty
certain your device
can't be condigured to have the 10 MHz connector be an
output for
anything.

Can you maybe describe the problem you're having?

Best regards,
Marcus

[1] https://files.ettus.com/schematics/b200/b210.pdf
On Fri, 2018-03-09 at 23:51 +, Sailor Jerry via
USRP-users wrote:
> I inherited the B210 board that has the 10 MHz
connector configured
> as an output. I wonder if anyone is aware of this
configuration and
> if it's possible to reconfigure it to accept the
external 10 MHz
> input.
>
> My current plan is simply remove GPSDO and hope for
the best.
>
> Attached are two pictures of my board. One is with
GPSDO inserted and
> another one with GPSDO removed.
>
> Thanks a lot!
>
>
>
> ___
> 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 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 mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] How to change B210 10Mz from Output to Input?

Thanks. Shall I ignore that sentence from USRP B2x0 Series manual "The B200
and B210 cannot support an external 10 MHz reference if a GPSDO is already
present on the motherboard. If an external 10 MHz is to be used, the GPSDO
needs to be physically removed from the device beforehand."?


On Fri, Mar 9, 2018 at 8:32 PM Marcus D. Leech  wrote:

> On 03/09/2018 11:25 PM, Sailor Jerry wrote:
>
> Would be happy to restore it to original condition :-)
>
> I'm using the uhd_rx_cfile to capture the data. How do I control U103 from
> this app? I don't see any command line arguments for that? Do I need to
> rebuild it?
>
> You'd have to add that, inserting a call to set_clock_source() at an
> appropriate place.
>
> The example apps (and this is one) don't necessarily expose all available
> features.
>
>
>
>
>
> On Fri, Mar 9, 2018 at 8:08 PM Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 03/09/2018 08:11 PM, Nick Foster wrote:
>>
>> It's a slick mod though. See the zero-ohm resistor bridging U103 pins 1
>> and 3? Remove it, and you'll return the B210 to factory standard.
>>
>> Assuming no other modifications have also been made.  =)
>>
>> Nick
>>
>> Your eyes are much better than mine
>>
>>
>>
>> On Fri, Mar 9, 2018 at 4:31 PM Marcus D. Leech via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> On 03/09/2018 07:22 PM, Sailor Jerry via USRP-users wrote:
>>>
>>> HI Marcus, I see your point and also saw the schematic. The previous
>>> owner told me that this particular board was modified to have 10 MHz be
>>> brought out to the outside connector. I did verify it with the scope and
>>> indeed saw the 10 MHz coming out. I don't know if it's one of the standard
>>> factory options or just some custom modifications (the board has
>>> Olifantasia label on it).  Will take a closer look at pins 3 and 1 of U103
>>> as you suggest.  If they are bridged indeed then I guess simple removal of
>>> GPSDO would do the trick.
>>>
>>>
>>> That is NOT a factory-standard option.
>>>
>>>
>>>
>>>
>>> On Fri, Mar 9, 2018 at 4:10 PM Marcus Müller 
>>> wrote:
>>>
 Dear Sailor Jerry,

 I'm not sure I'm following here: The 10 MHz connector is hardware-wise
 connected only to inputs, not to anything that can output anything;
 compare the schematic[1] on page 1. So, I'm pretty certain your device
 can't be condigured to have the 10 MHz connector be an output for
 anything.

 Can you maybe describe the problem you're having?

 Best regards,
 Marcus

 [1] https://files.ettus.com/schematics/b200/b210.pdf
 On Fri, 2018-03-09 at 23:51 +, Sailor Jerry via USRP-users wrote:
 > I inherited the B210 board that has the 10 MHz connector configured
 > as an output. I wonder if anyone is aware of this configuration and
 > if it's possible to reconfigure it to accept the external 10 MHz
 > input.
 >
 > My current plan is simply remove GPSDO and hope for the best.
 >
 > Attached are two pictures of my board. One is with GPSDO inserted and
 > another one with GPSDO removed.
 >
 > Thanks a lot!
 >
 >
 >
 > ___
 > USRP-users mailing list
 > USRP-users@lists.ettus.com
 > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

>>>
>>>
>>> ___
>>> USRP-users mailing 
>>> listUSRP-users@lists.ettus.comhttp://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 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] How to change B210 10Mz from Output to Input?

On 03/09/2018 11:44 PM, Sailor Jerry wrote:
Thanks. Shall I ignore that sentence from USRP B2x0 Series manual "The 
B200 and B210 cannot support an external 10 MHz reference if a GPSDO 
is already present on the motherboard. If an external 10 MHz is to be 
used, the GPSDO needs to be physically removed from the device 
beforehand."?

I think that advice is still correct, but I cannot remember why. Nick?

On Fri, Mar 9, 2018 at 8:32 PM Marcus D. Leech > wrote:

On 03/09/2018 11:25 PM, Sailor Jerry wrote:

Would be happy to restore it to original condition :-)

I'm using the uhd_rx_cfile to capture the data. How do I control
U103 from this app? I don't see any command line arguments for
that? Do I need to rebuild it?

You'd have to add that, inserting a call to set_clock_source() at
an appropriate place.

The example apps (and this is one) don't necessarily expose all
available features.

On Fri, Mar 9, 2018 at 8:08 PM Marcus D. Leech via USRP-users
mailto:usrp-users@lists.ettus.com>>
wrote:

On 03/09/2018 08:11 PM, Nick Foster wrote:

It's a slick mod though. See the zero-ohm resistor bridging
U103 pins 1 and 3? Remove it, and you'll return the B210 to
factory standard.

Assuming no other modifications have also been made.  =)

Nick

Your eyes are much better than mine

On Fri, Mar 9, 2018 at 4:31 PM Marcus D. Leech via
USRP-users mailto:usrp-users@lists.ettus.com>> wrote:

On 03/09/2018 07:22 PM, Sailor Jerry via USRP-users wrote:

HI Marcus, I see your point and also saw the schematic.
The previous owner told me that this particular board
was modified to have 10 MHz be brought out to the
outside connector. I did verify it with the scope and
indeed saw the 10 MHz coming out. I don't know if it's
one of the standard factory options or just some custom
modifications (the board has Olifantasia label on it).
Will take a closer look at pins 3 and 1 of U103 as you
suggest.  If they are bridged indeed then I guess
simple removal of GPSDO would do the trick.

That is NOT a factory-standard option.

On Fri, Mar 9, 2018 at 4:10 PM Marcus Müller
mailto:marcus.muel...@ettus.com>> wrote:

Dear Sailor Jerry,

I'm not sure I'm following here: The 10 MHz
connector is hardware-wise
connected only to inputs, not to anything that can
output anything;
compare the schematic[1] on page 1. So, I'm pretty
certain your device
can't be condigured to have the 10 MHz connector be
an output for
anything.

Can you maybe describe the problem you're having?

Best regards,
Marcus

[1] https://files.ettus.com/schematics/b200/b210.pdf
On Fri, 2018-03-09 at 23:51 +, Sailor Jerry via
USRP-users wrote:
> I inherited the B210 board that has the 10 MHz
connector configured
> as an output. I wonder if anyone is aware of this
configuration and
> if it's possible to reconfigure it to accept the
external 10 MHz
> input.
>
> My current plan is simply remove GPSDO and hope
for the best.
>
> Attached are two pictures of my board. One is
with GPSDO inserted and
> another one with GPSDO removed.
>
> Thanks a lot!
>
>
>
> ___
> 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 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] How to change B210 10Mz from Output to Input?

That sort of defeats the purpose of U103, doesn't it?

On Fri, Mar 9, 2018 at 8:48 PM Marcus D. Leech  wrote:

> On 03/09/2018 11:44 PM, Sailor Jerry wrote:
>
> Thanks. Shall I ignore that sentence from USRP B2x0 Series manual "The
> B200 and B210 cannot support an external 10 MHz reference if a GPSDO is
> already present on the motherboard. If an external 10 MHz is to be used,
> the GPSDO needs to be physically removed from the device beforehand."?
>
> I think that advice is still correct, but I cannot remember why.  Nick?
>
>
>
>
> On Fri, Mar 9, 2018 at 8:32 PM Marcus D. Leech  wrote:
>
>> On 03/09/2018 11:25 PM, Sailor Jerry wrote:
>>
>> Would be happy to restore it to original condition :-)
>>
>> I'm using the uhd_rx_cfile to capture the data. How do I control U103
>> from this app? I don't see any command line arguments for that? Do I need
>> to rebuild it?
>>
>> You'd have to add that, inserting a call to set_clock_source() at an
>> appropriate place.
>>
>> The example apps (and this is one) don't necessarily expose all available
>> features.
>>
>>
>>
>>
>>
>> On Fri, Mar 9, 2018 at 8:08 PM Marcus D. Leech via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> On 03/09/2018 08:11 PM, Nick Foster wrote:
>>>
>>> It's a slick mod though. See the zero-ohm resistor bridging U103 pins 1
>>> and 3? Remove it, and you'll return the B210 to factory standard.
>>>
>>> Assuming no other modifications have also been made.  =)
>>>
>>> Nick
>>>
>>> Your eyes are much better than mine
>>>
>>>
>>>
>>> On Fri, Mar 9, 2018 at 4:31 PM Marcus D. Leech via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 On 03/09/2018 07:22 PM, Sailor Jerry via USRP-users wrote:

 HI Marcus, I see your point and also saw the schematic. The previous
 owner told me that this particular board was modified to have 10 MHz be
 brought out to the outside connector. I did verify it with the scope and
 indeed saw the 10 MHz coming out. I don't know if it's one of the standard
 factory options or just some custom modifications (the board has
 Olifantasia label on it).  Will take a closer look at pins 3 and 1 of U103
 as you suggest.  If they are bridged indeed then I guess simple removal of
 GPSDO would do the trick.


 That is NOT a factory-standard option.




 On Fri, Mar 9, 2018 at 4:10 PM Marcus Müller 
 wrote:

> Dear Sailor Jerry,
>
> I'm not sure I'm following here: The 10 MHz connector is hardware-wise
> connected only to inputs, not to anything that can output anything;
> compare the schematic[1] on page 1. So, I'm pretty certain your device
> can't be condigured to have the 10 MHz connector be an output for
> anything.
>
> Can you maybe describe the problem you're having?
>
> Best regards,
> Marcus
>
> [1] https://files.ettus.com/schematics/b200/b210.pdf
> On Fri, 2018-03-09 at 23:51 +, Sailor Jerry via USRP-users wrote:
> > I inherited the B210 board that has the 10 MHz connector configured
> > as an output. I wonder if anyone is aware of this configuration and
> > if it's possible to reconfigure it to accept the external 10 MHz
> > input.
> >
> > My current plan is simply remove GPSDO and hope for the best.
> >
> > Attached are two pictures of my board. One is with GPSDO inserted and
> > another one with GPSDO removed.
> >
> > Thanks a lot!
> >
> >
> >
> > ___
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


 ___
 USRP-users mailing 
 listUSRP-users@lists.ettus.comhttp://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 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] How to change B210 10Mz from Output to Input?

I uh what? I don't see why that would be the case. The whole reason U103
exists is to switch between a GPSDO (if present) and an external reference.

You might wait for the official Ettus response for this if you don't want
to take responsibility for blowing it up, but I drew the schematic and I
say you're fine.

Incidentally, very early prototypes of the B200 used a neat PIN diode
switch ring which would allow outputting the GPSDO signal as well as using
either the reference port or GPSDO as a clock input. I can't remember why
it didn't make it into production, but one side effect would be that if
misconfigured, you could damage hardware. Maybe that was it. ;)

Nick

On Fri, Mar 9, 2018 at 8:48 PM Marcus D. Leech  wrote:

> On 03/09/2018 11:44 PM, Sailor Jerry wrote:
>
> Thanks. Shall I ignore that sentence from USRP B2x0 Series manual "The
> B200 and B210 cannot support an external 10 MHz reference if a GPSDO is
> already present on the motherboard. If an external 10 MHz is to be used,
> the GPSDO needs to be physically removed from the device beforehand."?
>
> I think that advice is still correct, but I cannot remember why.  Nick?
>
>
>
>
> On Fri, Mar 9, 2018 at 8:32 PM Marcus D. Leech  wrote:
>
>> On 03/09/2018 11:25 PM, Sailor Jerry wrote:
>>
>> Would be happy to restore it to original condition :-)
>>
>> I'm using the uhd_rx_cfile to capture the data. How do I control U103
>> from this app? I don't see any command line arguments for that? Do I need
>> to rebuild it?
>>
>> You'd have to add that, inserting a call to set_clock_source() at an
>> appropriate place.
>>
>> The example apps (and this is one) don't necessarily expose all available
>> features.
>>
>>
>>
>>
>>
>> On Fri, Mar 9, 2018 at 8:08 PM Marcus D. Leech via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> On 03/09/2018 08:11 PM, Nick Foster wrote:
>>>
>>> It's a slick mod though. See the zero-ohm resistor bridging U103 pins 1
>>> and 3? Remove it, and you'll return the B210 to factory standard.
>>>
>>> Assuming no other modifications have also been made.  =)
>>>
>>> Nick
>>>
>>> Your eyes are much better than mine
>>>
>>>
>>>
>>> On Fri, Mar 9, 2018 at 4:31 PM Marcus D. Leech via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 On 03/09/2018 07:22 PM, Sailor Jerry via USRP-users wrote:

 HI Marcus, I see your point and also saw the schematic. The previous
 owner told me that this particular board was modified to have 10 MHz be
 brought out to the outside connector. I did verify it with the scope and
 indeed saw the 10 MHz coming out. I don't know if it's one of the standard
 factory options or just some custom modifications (the board has
 Olifantasia label on it).  Will take a closer look at pins 3 and 1 of U103
 as you suggest.  If they are bridged indeed then I guess simple removal of
 GPSDO would do the trick.


 That is NOT a factory-standard option.




 On Fri, Mar 9, 2018 at 4:10 PM Marcus Müller 
 wrote:

> Dear Sailor Jerry,
>
> I'm not sure I'm following here: The 10 MHz connector is hardware-wise
> connected only to inputs, not to anything that can output anything;
> compare the schematic[1] on page 1. So, I'm pretty certain your device
> can't be condigured to have the 10 MHz connector be an output for
> anything.
>
> Can you maybe describe the problem you're having?
>
> Best regards,
> Marcus
>
> [1] https://files.ettus.com/schematics/b200/b210.pdf
> On Fri, 2018-03-09 at 23:51 +, Sailor Jerry via USRP-users wrote:
> > I inherited the B210 board that has the 10 MHz connector configured
> > as an output. I wonder if anyone is aware of this configuration and
> > if it's possible to reconfigure it to accept the external 10 MHz
> > input.
> >
> > My current plan is simply remove GPSDO and hope for the best.
> >
> > Attached are two pictures of my board. One is with GPSDO inserted and
> > another one with GPSDO removed.
> >
> > Thanks a lot!
> >
> >
> >
> > ___
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


 ___
 USRP-users mailing 
 listUSRP-users@lists.ettus.comhttp://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 mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>>
>
___
USRP-users mailing list
USRP-user

Re: [USRP-users] How to change B210 10Mz from Output to Input?

That would explain it , thanks :-)

On Fri, Mar 9, 2018 at 9:07 PM Nick Foster  wrote:

> I uh what? I don't see why that would be the case. The whole reason U103
> exists is to switch between a GPSDO (if present) and an external reference.
>
> You might wait for the official Ettus response for this if you don't want
> to take responsibility for blowing it up, but I drew the schematic and I
> say you're fine.
>
> Incidentally, very early prototypes of the B200 used a neat PIN diode
> switch ring which would allow outputting the GPSDO signal as well as using
> either the reference port or GPSDO as a clock input. I can't remember why
> it didn't make it into production, but one side effect would be that if
> misconfigured, you could damage hardware. Maybe that was it. ;)
>
> Nick
>
> On Fri, Mar 9, 2018 at 8:48 PM Marcus D. Leech  wrote:
>
>> On 03/09/2018 11:44 PM, Sailor Jerry wrote:
>>
>> Thanks. Shall I ignore that sentence from USRP B2x0 Series manual "The
>> B200 and B210 cannot support an external 10 MHz reference if a GPSDO is
>> already present on the motherboard. If an external 10 MHz is to be used,
>> the GPSDO needs to be physically removed from the device beforehand."?
>>
>> I think that advice is still correct, but I cannot remember why.  Nick?
>>
>>
>>
>>
>> On Fri, Mar 9, 2018 at 8:32 PM Marcus D. Leech  wrote:
>>
>>> On 03/09/2018 11:25 PM, Sailor Jerry wrote:
>>>
>>> Would be happy to restore it to original condition :-)
>>>
>>> I'm using the uhd_rx_cfile to capture the data. How do I control U103
>>> from this app? I don't see any command line arguments for that? Do I need
>>> to rebuild it?
>>>
>>> You'd have to add that, inserting a call to set_clock_source() at an
>>> appropriate place.
>>>
>>> The example apps (and this is one) don't necessarily expose all
>>> available features.
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Mar 9, 2018 at 8:08 PM Marcus D. Leech via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 On 03/09/2018 08:11 PM, Nick Foster wrote:

 It's a slick mod though. See the zero-ohm resistor bridging U103 pins 1
 and 3? Remove it, and you'll return the B210 to factory standard.

 Assuming no other modifications have also been made.  =)

 Nick

 Your eyes are much better than mine



 On Fri, Mar 9, 2018 at 4:31 PM Marcus D. Leech via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> On 03/09/2018 07:22 PM, Sailor Jerry via USRP-users wrote:
>
> HI Marcus, I see your point and also saw the schematic. The previous
> owner told me that this particular board was modified to have 10 MHz be
> brought out to the outside connector. I did verify it with the scope and
> indeed saw the 10 MHz coming out. I don't know if it's one of the standard
> factory options or just some custom modifications (the board has
> Olifantasia label on it).  Will take a closer look at pins 3 and 1 of U103
> as you suggest.  If they are bridged indeed then I guess simple removal of
> GPSDO would do the trick.
>
>
> That is NOT a factory-standard option.
>
>
>
>
> On Fri, Mar 9, 2018 at 4:10 PM Marcus Müller 
> wrote:
>
>> Dear Sailor Jerry,
>>
>> I'm not sure I'm following here: The 10 MHz connector is hardware-wise
>> connected only to inputs, not to anything that can output anything;
>> compare the schematic[1] on page 1. So, I'm pretty certain your device
>> can't be condigured to have the 10 MHz connector be an output for
>> anything.
>>
>> Can you maybe describe the problem you're having?
>>
>> Best regards,
>> Marcus
>>
>> [1] https://files.ettus.com/schematics/b200/b210.pdf
>> On Fri, 2018-03-09 at 23:51 +, Sailor Jerry via USRP-users wrote:
>> > I inherited the B210 board that has the 10 MHz connector configured
>> > as an output. I wonder if anyone is aware of this configuration and
>> > if it's possible to reconfigure it to accept the external 10 MHz
>> > input.
>> >
>> > My current plan is simply remove GPSDO and hope for the best.
>> >
>> > Attached are two pictures of my board. One is with GPSDO inserted
>> and
>> > another one with GPSDO removed.
>> >
>> > Thanks a lot!
>> >
>> >
>> >
>> > ___
>> > USRP-users mailing list
>> > USRP-users@lists.ettus.com
>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://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] How to change B210 10Mz from Output to Input?

Guys, thank you so much for your support, you are awesome!

Now I feel myself as complete idiot. I removed GPSDO. Disconnected the
10MHz clock, by USRP is still working and it seems to be on more or less
correct correct frequency. I clearly can see the input tone on fft utility.

Is there some other clock source I'm unaware off?  Can I see the ADF4001
lock status?  Here is the output I'm getting:
linux; GNU C++ version 5.3.1 20151219; Boost_105800;
UHD_003.009.002-0-unknown

-- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex...
-- Detected Device: B210
-- Loading FPGA image: /usr/share/uhd/images/usrp_b210_fpga.bin...
-- Operating over USB 3.
-- Detecting internal GPSDO No GPSDO found
-- Initialize CODEC control...
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Performing CODEC loopback test... pass
-- Asking for clock rate 16.00 MHz...
-- Actually got clock rate 16.00 MHz.
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
-- Setting master clock rate selection to 'automatic'.
-- Asking for clock rate 32.00 MHz...
-- Actually got clock rate 32.00 MHz.
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass




On Fri, Mar 9, 2018 at 9:09 PM Sailor Jerry 
wrote:

> That would explain it , thanks :-)
>
> On Fri, Mar 9, 2018 at 9:07 PM Nick Foster  wrote:
>
>> I uh what? I don't see why that would be the case. The whole reason U103
>> exists is to switch between a GPSDO (if present) and an external reference.
>>
>> You might wait for the official Ettus response for this if you don't want
>> to take responsibility for blowing it up, but I drew the schematic and I
>> say you're fine.
>>
>> Incidentally, very early prototypes of the B200 used a neat PIN diode
>> switch ring which would allow outputting the GPSDO signal as well as using
>> either the reference port or GPSDO as a clock input. I can't remember why
>> it didn't make it into production, but one side effect would be that if
>> misconfigured, you could damage hardware. Maybe that was it. ;)
>>
>> Nick
>>
>> On Fri, Mar 9, 2018 at 8:48 PM Marcus D. Leech  wrote:
>>
>>> On 03/09/2018 11:44 PM, Sailor Jerry wrote:
>>>
>>> Thanks. Shall I ignore that sentence from USRP B2x0 Series manual "The
>>> B200 and B210 cannot support an external 10 MHz reference if a GPSDO is
>>> already present on the motherboard. If an external 10 MHz is to be used,
>>> the GPSDO needs to be physically removed from the device beforehand."?
>>>
>>> I think that advice is still correct, but I cannot remember why.  Nick?
>>>
>>>
>>>
>>>
>>> On Fri, Mar 9, 2018 at 8:32 PM Marcus D. Leech 
>>> wrote:
>>>
 On 03/09/2018 11:25 PM, Sailor Jerry wrote:

 Would be happy to restore it to original condition :-)

 I'm using the uhd_rx_cfile to capture the data. How do I control U103
 from this app? I don't see any command line arguments for that? Do I need
 to rebuild it?

 You'd have to add that, inserting a call to set_clock_source() at an
 appropriate place.

 The example apps (and this is one) don't necessarily expose all
 available features.





 On Fri, Mar 9, 2018 at 8:08 PM Marcus D. Leech via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> On 03/09/2018 08:11 PM, Nick Foster wrote:
>
> It's a slick mod though. See the zero-ohm resistor bridging U103 pins
> 1 and 3? Remove it, and you'll return the B210 to factory standard.
>
> Assuming no other modifications have also been made.  =)
>
> Nick
>
> Your eyes are much better than mine
>
>
>
> On Fri, Mar 9, 2018 at 4:31 PM Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 03/09/2018 07:22 PM, Sailor Jerry via USRP-users wrote:
>>
>> HI Marcus, I see your point and also saw the schematic. The previous
>> owner told me that this particular board was modified to have 10 MHz be
>> brought out to the outside connector. I did verify it with the scope and
>> indeed saw the 10 MHz coming out. I don't know if it's one of the 
>> standard
>> factory options or just some custom modifications (the board has
>> Olifantasia label on it).  Will take a closer look at pins 3 and 1 of 
>> U103
>> as you suggest.  If they are bridged indeed then I guess simple removal 
>> of
>> GPSDO would do the trick.
>>
>>
>> That is NOT a factory-standard option.
>>
>>
>>
>>
>> On Fri, Mar 9, 2018 at 4:10 PM Marcus Müller <
>> marcus.muel...@ettus.com> wrote:
>>
>>> Dear Sailor Jerry,
>>>
>>> I'm not sure I'm following here: The 10 MHz connector is
>>> hardware-wise
>>> connected only to inputs, not to anything that can output anything;
>>> compare the schematic

Re: [USRP-users] How to change B210 10Mz from Output to Input?

Without an external reference, the onboard 40MHz VCTCXO will handle
creating a decent reference without the benefit of the PLL locking it to a
10MHz reference. Wouldn't be much use otherwise.

On Fri, Mar 9, 2018, 9:46 PM Sailor Jerry 
wrote:

> Guys, thank you so much for your support, you are awesome!
>
> Now I feel myself as complete idiot. I removed GPSDO. Disconnected the
> 10MHz clock, by USRP is still working and it seems to be on more or less
> correct correct frequency. I clearly can see the input tone on fft utility.
>
> Is there some other clock source I'm unaware off?  Can I see the ADF4001
> lock status?  Here is the output I'm getting:
> linux; GNU C++ version 5.3.1 20151219; Boost_105800;
> UHD_003.009.002-0-unknown
>
> -- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex...
> -- Detected Device: B210
> -- Loading FPGA image: /usr/share/uhd/images/usrp_b210_fpga.bin...
> -- Operating over USB 3.
> -- Detecting internal GPSDO No GPSDO found
> -- Initialize CODEC control...
> -- Initialize Radio control...
> -- Performing register loopback test... pass
> -- Performing register loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Asking for clock rate 16.00 MHz...
> -- Actually got clock rate 16.00 MHz.
> -- Performing timer loopback test... pass
> -- Performing timer loopback test... pass
> -- Setting master clock rate selection to 'automatic'.
> -- Asking for clock rate 32.00 MHz...
> -- Actually got clock rate 32.00 MHz.
> -- Performing timer loopback test... pass
> -- Performing timer loopback test... pass
>
>
>
>
> On Fri, Mar 9, 2018 at 9:09 PM Sailor Jerry 
> wrote:
>
>> That would explain it , thanks :-)
>>
>> On Fri, Mar 9, 2018 at 9:07 PM Nick Foster  wrote:
>>
>>> I uh what? I don't see why that would be the case. The whole reason U103
>>> exists is to switch between a GPSDO (if present) and an external reference.
>>>
>>> You might wait for the official Ettus response for this if you don't
>>> want to take responsibility for blowing it up, but I drew the schematic and
>>> I say you're fine.
>>>
>>> Incidentally, very early prototypes of the B200 used a neat PIN diode
>>> switch ring which would allow outputting the GPSDO signal as well as using
>>> either the reference port or GPSDO as a clock input. I can't remember why
>>> it didn't make it into production, but one side effect would be that if
>>> misconfigured, you could damage hardware. Maybe that was it. ;)
>>>
>>> Nick
>>>
>>> On Fri, Mar 9, 2018 at 8:48 PM Marcus D. Leech 
>>> wrote:
>>>
 On 03/09/2018 11:44 PM, Sailor Jerry wrote:

 Thanks. Shall I ignore that sentence from USRP B2x0 Series manual "The
 B200 and B210 cannot support an external 10 MHz reference if a GPSDO is
 already present on the motherboard. If an external 10 MHz is to be used,
 the GPSDO needs to be physically removed from the device beforehand."?

 I think that advice is still correct, but I cannot remember why.  Nick?




 On Fri, Mar 9, 2018 at 8:32 PM Marcus D. Leech 
 wrote:

> On 03/09/2018 11:25 PM, Sailor Jerry wrote:
>
> Would be happy to restore it to original condition :-)
>
> I'm using the uhd_rx_cfile to capture the data. How do I control U103
> from this app? I don't see any command line arguments for that? Do I need
> to rebuild it?
>
> You'd have to add that, inserting a call to set_clock_source() at an
> appropriate place.
>
> The example apps (and this is one) don't necessarily expose all
> available features.
>
>
>
>
>
> On Fri, Mar 9, 2018 at 8:08 PM Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 03/09/2018 08:11 PM, Nick Foster wrote:
>>
>> It's a slick mod though. See the zero-ohm resistor bridging U103 pins
>> 1 and 3? Remove it, and you'll return the B210 to factory standard.
>>
>> Assuming no other modifications have also been made.  =)
>>
>> Nick
>>
>> Your eyes are much better than mine
>>
>>
>>
>> On Fri, Mar 9, 2018 at 4:31 PM Marcus D. Leech via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> On 03/09/2018 07:22 PM, Sailor Jerry via USRP-users wrote:
>>>
>>> HI Marcus, I see your point and also saw the schematic. The previous
>>> owner told me that this particular board was modified to have 10 MHz be
>>> brought out to the outside connector. I did verify it with the scope and
>>> indeed saw the 10 MHz coming out. I don't know if it's one of the 
>>> standard
>>> factory options or just some custom modifications (the board has
>>> Olifantasia label on it).  Will take a closer look at pins 3 and 1 of 
>>> U103
>>> as you suggest.  If they are bridged indeed then I guess simple removal 
>>> of
>>> GPSDO would do the trick.
>>>
>>

Re: [USRP-users] How to change B210 10Mz from Output to Input?

Thanks a lot Nick, is there way to find out if the PLL is locked or not?
Can it be done via SW or I need to probe MUXOUT of U101. What should I see
there?

The reason I need to know it, I want to make sure I'm locked to external 10
MHz. Now for some reasons I see the input tone few tens of  KHz off from
where I expect to see it.


On Fri, Mar 9, 2018 at 9:52 PM Nick Foster  wrote:

> Without an external reference, the onboard 40MHz VCTCXO will handle
> creating a decent reference without the benefit of the PLL locking it to a
> 10MHz reference. Wouldn't be much use otherwise.
>
> On Fri, Mar 9, 2018, 9:46 PM Sailor Jerry 
> wrote:
>
>> Guys, thank you so much for your support, you are awesome!
>>
>> Now I feel myself as complete idiot. I removed GPSDO. Disconnected the
>> 10MHz clock, by USRP is still working and it seems to be on more or less
>> correct correct frequency. I clearly can see the input tone on fft utility.
>>
>> Is there some other clock source I'm unaware off?  Can I see the ADF4001
>> lock status?  Here is the output I'm getting:
>> linux; GNU C++ version 5.3.1 20151219; Boost_105800;
>> UHD_003.009.002-0-unknown
>>
>> -- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex...
>> -- Detected Device: B210
>> -- Loading FPGA image: /usr/share/uhd/images/usrp_b210_fpga.bin...
>> -- Operating over USB 3.
>> -- Detecting internal GPSDO No GPSDO found
>> -- Initialize CODEC control...
>> -- Initialize Radio control...
>> -- Performing register loopback test... pass
>> -- Performing register loopback test... pass
>> -- Performing CODEC loopback test... pass
>> -- Performing CODEC loopback test... pass
>> -- Asking for clock rate 16.00 MHz...
>> -- Actually got clock rate 16.00 MHz.
>> -- Performing timer loopback test... pass
>> -- Performing timer loopback test... pass
>> -- Setting master clock rate selection to 'automatic'.
>> -- Asking for clock rate 32.00 MHz...
>> -- Actually got clock rate 32.00 MHz.
>> -- Performing timer loopback test... pass
>> -- Performing timer loopback test... pass
>>
>>
>>
>>
>> On Fri, Mar 9, 2018 at 9:09 PM Sailor Jerry 
>> wrote:
>>
>>> That would explain it , thanks :-)
>>>
>>> On Fri, Mar 9, 2018 at 9:07 PM Nick Foster  wrote:
>>>
 I uh what? I don't see why that would be the case. The whole reason
 U103 exists is to switch between a GPSDO (if present) and an external
 reference.

 You might wait for the official Ettus response for this if you don't
 want to take responsibility for blowing it up, but I drew the schematic and
 I say you're fine.

 Incidentally, very early prototypes of the B200 used a neat PIN diode
 switch ring which would allow outputting the GPSDO signal as well as using
 either the reference port or GPSDO as a clock input. I can't remember why
 it didn't make it into production, but one side effect would be that if
 misconfigured, you could damage hardware. Maybe that was it. ;)

 Nick

 On Fri, Mar 9, 2018 at 8:48 PM Marcus D. Leech 
 wrote:

> On 03/09/2018 11:44 PM, Sailor Jerry wrote:
>
> Thanks. Shall I ignore that sentence from USRP B2x0 Series manual "The
> B200 and B210 cannot support an external 10 MHz reference if a GPSDO is
> already present on the motherboard. If an external 10 MHz is to be used,
> the GPSDO needs to be physically removed from the device beforehand."?
>
>
> I think that advice is still correct, but I cannot remember why.  Nick?
>
>
>
>
> On Fri, Mar 9, 2018 at 8:32 PM Marcus D. Leech 
> wrote:
>
>> On 03/09/2018 11:25 PM, Sailor Jerry wrote:
>>
>> Would be happy to restore it to original condition :-)
>>
>> I'm using the uhd_rx_cfile to capture the data. How do I control U103
>> from this app? I don't see any command line arguments for that? Do I need
>> to rebuild it?
>>
>> You'd have to add that, inserting a call to set_clock_source() at an
>> appropriate place.
>>
>> The example apps (and this is one) don't necessarily expose all
>> available features.
>>
>>
>>
>>
>>
>> On Fri, Mar 9, 2018 at 8:08 PM Marcus D. Leech via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> On 03/09/2018 08:11 PM, Nick Foster wrote:
>>>
>>> It's a slick mod though. See the zero-ohm resistor bridging U103
>>> pins 1 and 3? Remove it, and you'll return the B210 to factory standard.
>>>
>>> Assuming no other modifications have also been made.  =)
>>>
>>> Nick
>>>
>>> Your eyes are much better than mine
>>>
>>>
>>>
>>> On Fri, Mar 9, 2018 at 4:31 PM Marcus D. Leech via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 On 03/09/2018 07:22 PM, Sailor Jerry via USRP-users wrote:

 HI Marcus, I see your point and also saw the schematic. The
 previous owner told me that this pa

Re: [USRP-users] How to change B210 10Mz from Output to Input?

On 03/10/2018 12:59 AM, Sailor Jerry wrote:
Thanks a lot Nick, is there way to find out if the PLL is locked or
not? Can it be done via SW or I need to probe MUXOUT of U101. What
should I see there?

The reason I need to know it, I want to make sure I'm locked to
external 10 MHz. Now for some reasons I see the input tone few tens
of KHz off from where I expect to see it.

There is a ref_locked sensor, you can read it with get_mboard_sensor():

https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a2d3c327bcb83fd274e05e3ca95d1ac95

The on-board clock is 2.5PPM.

On Fri, Mar 9, 2018 at 9:52 PM Nick Foster > wrote:

Without an external reference, the onboard 40MHz VCTCXO will
handle creating a decent reference without the benefit of the PLL
locking it to a 10MHz reference. Wouldn't be much use otherwise.

On Fri, Mar 9, 2018, 9:46 PM Sailor Jerry
mailto:sailorje...@scmarinetech.com>> wrote:

Guys, thank you so much for your support, you are awesome!

Now I feel myself as complete idiot. I removed GPSDO.
Disconnected the 10MHz clock, by USRP is still working and it
seems to be on more or less correct correct frequency. I
clearly can see the input tone on fft utility.

Is there some other clock source I'm unaware off? Can I see
the ADF4001 lock status? Here is the output I'm getting:
linux; GNU C++ version 5.3.1 20151219; Boost_105800;
UHD_003.009.002-0-unknown

-- Loading firmware image:
/usr/share/uhd/images/usrp_b200_fw.hex...
-- Detected Device: B210
-- Loading FPGA image: /usr/share/uhd/images/usrp_b210_fpga.bin...
-- Operating over USB 3.
-- Detecting internal GPSDO No GPSDO found
-- Initialize CODEC control...
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Performing CODEC loopback test... pass
-- Asking for clock rate 16.00 MHz...
-- Actually got clock rate 16.00 MHz.
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
-- Setting master clock rate selection to 'automatic'.
-- Asking for clock rate 32.00 MHz...
-- Actually got clock rate 32.00 MHz.
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass

On Fri, Mar 9, 2018 at 9:09 PM Sailor Jerry
mailto:sailorje...@scmarinetech.com>> wrote:

That would explain it , thanks :-)

On Fri, Mar 9, 2018 at 9:07 PM Nick Foster
mailto:bistrom...@gmail.com>> wrote:

I uh what? I don't see why that would be the case. The
whole reason U103 exists is to switch between a GPSDO
(if present) and an external reference.

You might wait for the official Ettus response for
this if you don't want to take responsibility for
blowing it up, but I drew the schematic and I say
you're fine.

Incidentally, very early prototypes of the B200 used a
neat PIN diode switch ring which would allow
outputting the GPSDO signal as well as using either
the reference port or GPSDO as a clock input. I can't
remember why it didn't make it into production, but
one side effect would be that if misconfigured, you
could damage hardware. Maybe that was it. ;)

Nick

On Fri, Mar 9, 2018 at 8:48 PM Marcus D. Leech
mailto:mle...@ripnet.com>> wrote:

On 03/09/2018 11:44 PM, Sailor Jerry wrote:

Thanks. Shall I ignore that sentence from USRP
B2x0 Series manual "The B200 and B210 cannot
support an external 10 MHz reference if a GPSDO
is already present on the motherboard. If an
external 10 MHz is to be used, the GPSDO needs to
be physically removed from the device beforehand."?

I think that advice is still correct, but I cannot
remember why. Nick?

On Fri, Mar 9, 2018 at 8:32 PM Marcus D. Leech
mailto:mle...@ripnet.com>> wrote:

On 03/09/2018 11:25 PM, Sailor Jerry wrote:

Would be happy to restore it to original
condition :-)

I'm using the uhd_rx_cfile to capture the
data. How do I control U103 from this app? I
don't see any command line arguments for
that? Do I need to rebuild it?

Re: [USRP-users] How to change B210 10Mz from Output to Input?