Re: [USRP-users] Phase jumps in USRP B210 with GPSDO

2017-09-21 Thread Marcus D. Leech via USRP-users 

On 09/21/2017 02:27 PM, Piotr Krysik via USRP-users wrote:


--
Piotr Krysik


Also take into account that I'm not comparing phase signals observed by
two different USRPs. What I have shown is for single channel of one USRP
in which such jumps are observed (I'm comparing phase of digitally
generated sinusoid with phase of recorded one). Same thing, however, can
be observed when recording signal with two USRPS in situation where one
have board mounted GPSDO and another one doesn't (with simple
unwrap(angle(x1.*conj(x2))) where x1 and x2 are signal vectors). Both
USRPs synchronized with use of Octoclock-G.

To make the matter simpler to gasp I will check if the same problem can
be observed on one USRP B210 with board mounted GPSDO - without any
additional hardware.


I use B210s for interferometry.  Phase coherence is stable basically 
"forever" between two B210 RX channels, regardless of the reference 
used, since the
  LO is shared between the two receive channels.  So, absent bugs in 
the FPGA digital processing, I'd be very surprised to see phase-hits 
within a single

  B210.



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

Re: [USRP-users] Verifying MIMO cable integrity

2017-09-21 Thread Nate Temple via USRP-users 
Hi John,

I've matched your configuration, with a N210 with GPSDO as master, and a
N210 slave connected via a MIMO cable. I was able to create a pair of
synced streams with the flowgraph attached without issue. Can you give it a
try? Otherwise email us at supp...@ettus.com and we can follow up there.

Regards,
Nate Temple



On Thu, Sep 21, 2017 at 1:21 PM, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> That seems correct to me, but I don't have a useful configuration in my
> lab to test.  (No N2xx, no MIMO cables).
>
>
>
>
>
>
>
>
> On 2017-09-21 16:02, John Shields via USRP-users wrote:
>
> Hi,
> I have been struggling with trying to get two coherent channels from a
> pair of N200 , one with GPSDO and the other with a MIMO cable. I realise
> that, according to the sync_page doc, I need to do some software magic in
> order to attempt to phase-sync but the slave unit reports that it cannot
> detect the PPS in time. While trying various options (e.g. moving the GPSDO
> from one N200r4 to the other) the conclusion appeared to be that each N200
> was OK and that either the MIMO cable was faulty (unlikely) or there is a
> software problem with UHD.
>
>   What I am now attempting to do is to take the GPSDO module out of the
> equation and test purely the MIMO cable/software. I have separated out the
> UHD sources in GRC so I have some control – not all control unfortunately
> because if there is a GPSDO, it appears that it is detected and used no
> matter the settings but that can be easily remedied.
>
>   So, after removing UART connection on GPSDO, I have 2 free-running N200s
> – I want to make one the 'master' so I have set Red:  Sync = Don't Sync,
> Clock Source = Internal, Time source=Default.
>
>   On the other unit, Blue, I have set : Sync= Don't Sync, Clock Source and
> Time Source= MIMO Cable. If I set the sync parameter to "unknown PPS" we
> are back to the situation where there is no PPS detected.
>
> Are these the correct settings to test the integrity of the MIMO cable
> and/or UHD sync software?
>
>   Kind Regards,
>
>John
>
>
>
>
> 
>  Virus-free.
> www.avast.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
>
>


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

Re: [USRP-users] E310 "subdev spec" equivalent in RFNoC?

2017-09-21 Thread Tom Bereknyei via USRP-users 
EJ,

I went through that same sequence of attempts and never got a solution
other than using TX/RX and RX2 on the same A channel.

On Thu, Sep 21, 2017 at 14:05 EJ Kreinar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I'm trying to specify exactly which channel to record from an RFNoC
> flowgraph on the E310, but I cant seem to get this to work
>
> Typically, in non-RFNoC applications, or in the "legacy_compat" mode, you
> can use the following options:
>
> uhd_rx_cfile -r  -f  -A TX/RX --spec=A:A
> recording.c32
> uhd_rx_cfile -r  -f  -A RX2 --spec=A:A
> recording.c32
> uhd_rx_cfile -r  -f  -A TX/RX --spec=A:B
> recording.c32
> uhd_rx_cfile -r  -f  -A RX2 --spec=A:B
> recording.c32
>
> And each option, in turn, records data from a different receive port on
> the E310.
>
>
> But, I cant figure out the correct combination to get the rfnoc_radio
> software to support recording on channel B. A few things I've tried:
>
> 1. Changing the rfnoc_radio dropdown to "Radio Select = B". This errors
> like this:
>
> Traceback (most recent call last):
>   File "/home/root/test_rx.py", line 138, in 
> main()
>   File "/home/root/test_rx.py", line 127, in main
> tb = top_block_cls(args=options.args, freq=options.freq,
> gain=options.gain, rate=options.rate)
>   File "/home/root/test_rx.py", line 52, in __init__
> 1, -1
>   File "/usr/lib/python2.7/site-packages/ettus/ettus_swig.py", line 1980,
> in make
> return _ettus_swig.rfnoc_radio_make(*args, **kwargs)
> RuntimeError: Cannot find a block for ID: Radio_1
> -- Loading FPGA image: /boot/system_top.bit... done
>
>
> 2. Adding a FIFO to the FPGA on the second channel, and "dropping" the
> samples from the first channel.
> [image: Inline image 1]
>
> But this fails like so:
>
> -- [0/FIFO_0] source_node_ctrl::set_rx_streamer() 0 -> 1
> -- [0/Radio_0] radio_ctrl_impl::set_rx_streamer() 1 -> 1
> -- [0/Radio_0] e3xx_radio_ctrl_impl::_update_enables()
> -- [0/Radio_0] e3xx_radio_ctrl_impl::_update_gpio_state()
> -- [Device3] updating RX streamer to RX Terminator 0
> --   New tick_rate == 25  New samp_rate == 25 New scaling ==
> 3.05185e-05
> -- [0/FIFO_0] source_block_ctrl_base::issue_stream_cmd()
> -- [0/Radio_0] radio_ctrl_impl::issue_stream_cmd() 0 a
> -- [0/Radio_0] radio_ctrl_impl::issue_stream_cmd() called on inactive
> channel. Skipping.
> timeout on chan 0
> timeout on chan 0
>
> And no data is recorded.
>
> 3. I also tried (foolishly) manually editing the generated python to
> connect the File Sink to port 1 of the rfnoc_radio, rather than port 0.
>
> I used this flowgraph:
> [image: Inline image 3]
> And then I manually changed the following lines:
>
> self.connect((self.uhd_rfnoc_streamer_radio_0, 0),
> (self.blocks_file_sink_0_0, 0))
> =becomes==>
> self.connect((self.uhd_rfnoc_streamer_radio_0, 1),
> (self.blocks_file_sink_0_0, 0))
>
> I was hopeful that port 1 actually existed and was initialized correctly
> in UHD, but alas, port 1 clearly does not exist for me to attach the file
> sink to:
>
> Traceback (most recent call last):
>   File "/home/root/test_rx.py", line 138, in 
> main()
>   File "/home/root/test_rx.py", line 128, in main
> tb.start()
>   File "/usr/lib/python2.7/site-packages/gnuradio/gr/top_block.py", line
> 109, in start
> top_block_start_unlocked(self._impl, max_noutput_items)
>   File "/usr/lib/python2.7/site-packages/gnuradio/gr/runtime_swig.py",
> line 3671, in top_block_start_unlocked
> return _runtime_swig.top_block_start_unlocked(*args, **kwargs)
> RuntimeError: rfnoc_radio(1): missing connection from output port 0
> -- Loading FPGA image: /boot/system_top.bit... done
>
>
> I cant seem to figure this out.. Any suggestions?? Am I missing something
> obvious, or is RFNoC missing this support?
>
> (by the way, I am admittedly still behind on my UHD version. So perhaps
> there's updates that resolve this issue recently?)
>
> Thanks!
> EJ
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-- 
Maj Tom Bereknyei
Defense Digital Service
t...@dds.mil
(571) 225-1630‬
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Verifying MIMO cable integrity

2017-09-21 Thread Marcus D. Leech via USRP-users 
That seems correct to me, but I don't have a useful configuration in my
lab to test.  (No N2xx, no MIMO cables). 

On 2017-09-21 16:02, John Shields via USRP-users wrote:

> Hi, 
> I have been struggling with trying to get two coherent channels from a pair 
> of N200 , one with GPSDO and the other with a MIMO cable. I realise that, 
> according to the sync_page doc, I need to do some software magic in order to 
> attempt to phase-sync but the slave unit reports that it cannot detect the 
> PPS in time. While trying various options (e.g. moving the GPSDO from one 
> N200r4 to the other) the conclusion appeared to be that each N200 was OK and 
> that either the MIMO cable was faulty (unlikely) or there is a software 
> problem with UHD. 
> 
> What I am now attempting to do is to take the GPSDO module out of the 
> equation and test purely the MIMO cable/software. I have separated out the 
> UHD sources in GRC so I have some control - not all control unfortunately 
> because if there is a GPSDO, it appears that it is detected and used no 
> matter the settings but that can be easily remedied. 
> 
> So, after removing UART connection on GPSDO, I have 2 free-running N200s - I 
> want to make one the 'master' so I have set Red:  Sync = Don't Sync, Clock 
> Source = Internal, Time source=Default. 
> 
> On the other unit, Blue, I have set : Sync= Don't Sync, Clock Source and Time 
> Source= MIMO Cable. If I set the sync parameter to "unknown PPS" we are back 
> to the situation where there is no PPS detected. 
> 
> Are these the correct settings to test the integrity of the MIMO cable and/or 
> UHD sync software? 
> 
> Kind Regards, 
> 
> John 
> 
> [1]
> Virus-free. www.avast.com [1]
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
 

Links:
--
[1]
https://www.avast.com/sig-email?utm_medium=emailutm_source=linkutm_campaign=sig-emailutm_content=emailclient___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Verifying MIMO cable integrity

2017-09-21 Thread John Shields via USRP-users 
Hi,
I have been struggling with trying to get two coherent channels from a pair 
of N200 , one with GPSDO and the other with a MIMO cable. I realise that, 
according to the sync_page doc, I need to do some software magic in order to 
attempt to phase-sync but the slave unit reports that it cannot detect the PPS 
in time. While trying various options (e.g. moving the GPSDO from one N200r4 to 
the other) the conclusion appeared to be that each N200 was OK and that either 
the MIMO cable was faulty (unlikely) or there is a software problem with UHD.

  What I am now attempting to do is to take the GPSDO module out of the 
equation and test purely the MIMO cable/software. I have separated out the UHD 
sources in GRC so I have some control – not all control unfortunately because 
if there is a GPSDO, it appears that it is detected and used no matter the 
settings but that can be easily remedied.

  So, after removing UART connection on GPSDO, I have 2 free-running N200s – I 
want to make one the ‘master’ so I have set Red:  Sync = Don’t Sync, Clock 
Source = Internal, Time source=Default.

  On the other unit, Blue, I have set : Sync= Don’t Sync, Clock Source and Time 
Source= MIMO Cable. If I set the sync parameter to “unknown PPS” we are back to 
the situation where there is no PPS detected.

Are these the correct settings to test the integrity of the MIMO cable and/or 
UHD sync software?

  Kind Regards,

   John



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Phase jumps in USRP B210 with GPSDO

2017-09-21 Thread Piotr Krysik via USRP-users 
W dniu 21.09.2017 o 19:16, Piotr Krysik via USRP-users pisze:
> W dniu 21.09.2017 o 17:19, mle...@ripnet.com pisze:
>> You talk about board-mounted GPSDOs in each of your B210s, but then
>> talk about using an Octoclock-G.
>>
>> In the Octoclock-G example, you are explicitly selecting "external"
>> for your refclock and time source?
>>
>> It is fully-expected that no two GPSDOs will precisely agree on
>> frequency and phase, and will have some amount of mutual phase-noise. 
>> Even when fed with the same antenna. 
>>
> I explicitly written that I configured USRPs to take PPS and 10MHz ref
> from external inputs. We just happen to have board mounted GPSDOs in all
> USRPs B210 that we have, but in this example they were not used for
> synchronization.
>
> --
> Piotr Krysik
>
>
Also take into account that I'm not comparing phase signals observed by
two different USRPs. What I have shown is for single channel of one USRP
in which such jumps are observed (I'm comparing phase of digitally
generated sinusoid with phase of recorded one). Same thing, however, can
be observed when recording signal with two USRPS in situation where one
have board mounted GPSDO and another one doesn't (with simple
unwrap(angle(x1.*conj(x2))) where x1 and x2 are signal vectors). Both
USRPs synchronized with use of Octoclock-G.

To make the matter simpler to gasp I will check if the same problem can
be observed on one USRP B210 with board mounted GPSDO - without any
additional hardware.

--
Piotr Krysik

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

[USRP-users] E310 "subdev spec" equivalent in RFNoC?

2017-09-21 Thread EJ Kreinar via USRP-users 
Hi all,

I'm trying to specify exactly which channel to record from an RFNoC
flowgraph on the E310, but I cant seem to get this to work

Typically, in non-RFNoC applications, or in the "legacy_compat" mode, you
can use the following options:

uhd_rx_cfile -r  -f  -A TX/RX --spec=A:A
recording.c32
uhd_rx_cfile -r  -f  -A RX2 --spec=A:A recording.c32
uhd_rx_cfile -r  -f  -A TX/RX --spec=A:B
recording.c32
uhd_rx_cfile -r  -f  -A RX2 --spec=A:B recording.c32

And each option, in turn, records data from a different receive port on the
E310.


But, I cant figure out the correct combination to get the rfnoc_radio
software to support recording on channel B. A few things I've tried:

1. Changing the rfnoc_radio dropdown to "Radio Select = B". This errors
like this:

Traceback (most recent call last):
  File "/home/root/test_rx.py", line 138, in 
main()
  File "/home/root/test_rx.py", line 127, in main
tb = top_block_cls(args=options.args, freq=options.freq,
gain=options.gain, rate=options.rate)
  File "/home/root/test_rx.py", line 52, in __init__
1, -1
  File "/usr/lib/python2.7/site-packages/ettus/ettus_swig.py", line 1980,
in make
return _ettus_swig.rfnoc_radio_make(*args, **kwargs)
RuntimeError: Cannot find a block for ID: Radio_1
-- Loading FPGA image: /boot/system_top.bit... done


2. Adding a FIFO to the FPGA on the second channel, and "dropping" the
samples from the first channel.
[image: Inline image 1]

But this fails like so:

-- [0/FIFO_0] source_node_ctrl::set_rx_streamer() 0 -> 1
-- [0/Radio_0] radio_ctrl_impl::set_rx_streamer() 1 -> 1
-- [0/Radio_0] e3xx_radio_ctrl_impl::_update_enables()
-- [0/Radio_0] e3xx_radio_ctrl_impl::_update_gpio_state()
-- [Device3] updating RX streamer to RX Terminator 0
--   New tick_rate == 25  New samp_rate == 25 New scaling ==
3.05185e-05
-- [0/FIFO_0] source_block_ctrl_base::issue_stream_cmd()
-- [0/Radio_0] radio_ctrl_impl::issue_stream_cmd() 0 a
-- [0/Radio_0] radio_ctrl_impl::issue_stream_cmd() called on inactive
channel. Skipping.
timeout on chan 0
timeout on chan 0

And no data is recorded.

3. I also tried (foolishly) manually editing the generated python to
connect the File Sink to port 1 of the rfnoc_radio, rather than port 0.

I used this flowgraph:
[image: Inline image 3]
And then I manually changed the following lines:

self.connect((self.uhd_rfnoc_streamer_radio_0, 0),
(self.blocks_file_sink_0_0, 0))
=becomes==>
self.connect((self.uhd_rfnoc_streamer_radio_0, 1),
(self.blocks_file_sink_0_0, 0))

I was hopeful that port 1 actually existed and was initialized correctly in
UHD, but alas, port 1 clearly does not exist for me to attach the file sink
to:

Traceback (most recent call last):
  File "/home/root/test_rx.py", line 138, in 
main()
  File "/home/root/test_rx.py", line 128, in main
tb.start()
  File "/usr/lib/python2.7/site-packages/gnuradio/gr/top_block.py", line
109, in start
top_block_start_unlocked(self._impl, max_noutput_items)
  File "/usr/lib/python2.7/site-packages/gnuradio/gr/runtime_swig.py", line
3671, in top_block_start_unlocked
return _runtime_swig.top_block_start_unlocked(*args, **kwargs)
RuntimeError: rfnoc_radio(1): missing connection from output port 0
-- Loading FPGA image: /boot/system_top.bit... done


I cant seem to figure this out.. Any suggestions?? Am I missing something
obvious, or is RFNoC missing this support?

(by the way, I am admittedly still behind on my UHD version. So perhaps
there's updates that resolve this issue recently?)

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

Re: [USRP-users] Help - Unbrick N200

2017-09-21 Thread Neel Pandeya via USRP-users 
Take a look at this Application Note.

https://kb.ettus.com/N200/N210_Device_Recovery

--​Neel Pandeya




On 21 September 2017 at 09:26, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 09/21/2017 12:12 PM, Chun Yang - Sigem via USRP-users wrote:
>
> I need to use N200 for a project. However, its LED D does not lit up (no
> firmware) and no response when pinging through the Ethernet connection.
> Followed the instruction on Ettus website to unbrick this N200 and here is
> what I got (from a Windows 10 laptop computer).
>
>
>
> With an Xilinx Platform Cable, I was able to use Xilinx Impact to load “
> usrp_n210_r4_fpga.bit” via the programmer. LED D was lit up now and
> Ethernet connection was established as I can ping and get response from
> N200.
>
>
>
> Then I was also able to use MATLAB to load the firmware and FPGA images to
> N200. The operation was successful and I was able to find the device in
> MATLAB and read back the device status info.
>
>
>
> However, after power-off and power on again, N200 went back to the old
> dead condition again. It looks like the firmware was not permanently burned
> into the device EEPROM as it is supposed so.
>
>
>
> I may have missed one step or two. Any suggestions?
>
>
>
> Thanks,
>
>
>
> Chun
>
>
>
> It's likely that it's just an IP address issue.  When in "safe mode", the
> device adopts a standardized IP address.  But once you power-cycle out of
> "safe mode",
>it'll take on whatever is programmed into the EEPROM for its IP address.
>
> Bring the device back into "safe mode", and use the usrp_burn_mb_eeprom
> utility to program your desired IP address while the device is in safe
> mode, using the default safe-mode address.
>
>
>
> ___
> 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] Phase jumps in USRP B210 with GPSDO

2017-09-21 Thread Piotr Krysik via USRP-users 
W dniu 21.09.2017 o 17:19, mle...@ripnet.com pisze:
>
> You talk about board-mounted GPSDOs in each of your B210s, but then
> talk about using an Octoclock-G.
>
> In the Octoclock-G example, you are explicitly selecting "external"
> for your refclock and time source?
>
> It is fully-expected that no two GPSDOs will precisely agree on
> frequency and phase, and will have some amount of mutual phase-noise. 
> Even when fed with the same antenna. 
>
I explicitly written that I configured USRPs to take PPS and 10MHz ref
from external inputs. We just happen to have board mounted GPSDOs in all
USRPs B210 that we have, but in this example they were not used for
synchronization.

--
Piotr Krysik


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

Re: [USRP-users] Help - Unbrick N200

2017-09-21 Thread Marcus D. Leech via USRP-users 

On 09/21/2017 12:12 PM, Chun Yang - Sigem via USRP-users wrote:


I need to use N200 for a project. However, its LED D does not lit up 
(no firmware) and no response when pinging through the Ethernet 
connection. Followed the instruction on Ettus website to unbrick this 
N200 and here is what I got (from a Windows 10 laptop computer).


With an Xilinx Platform Cable, I was able to use Xilinx Impact to 
load “|usrp_n210_r4_fpga.bit”| via the programmer. LED D was lit up 
now and Ethernet connection was established as I can ping and get 
response from N200.


Then I was also able to use MATLAB to load the firmware and FPGA 
images to N200. The operation was successful and I was able to find 
the device in MATLAB and read back the device status info.


However, after power-off and power on again, N200 went back to the old 
dead condition again. It looks like the firmware was not permanently 
burned into the device EEPROM as it is supposed so.


I may have missed one step or two. Any suggestions?

Thanks,

Chun


It's likely that it's just an IP address issue.  When in "safe mode", 
the device adopts a standardized IP address.  But once you power-cycle 
out of "safe mode",

   it'll take on whatever is programmed into the EEPROM for its IP address.

Bring the device back into "safe mode", and use the usrp_burn_mb_eeprom  
utility to program your desired IP address while the device is in safe 
mode, using the default safe-mode address.



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

[USRP-users] Help - Unbrick N200

2017-09-21 Thread Chun Yang - Sigem via USRP-users 
I need to use N200 for a project. However, its LED D does not lit up (no
firmware) and no response when pinging through the Ethernet connection.
Followed the instruction on Ettus website to unbrick this N200 and here is
what I got (from a Windows 10 laptop computer).

 

With an Xilinx Platform Cable, I was able to use Xilinx Impact to load
"usrp_n210_r4_fpga.bit" via the programmer. LED D was lit up now and
Ethernet connection was established as I can ping and get response from
N200.

 

Then I was also able to use MATLAB to load the firmware and FPGA images to
N200. The operation was successful and I was able to find the device in
MATLAB and read back the device status info.

 

However, after power-off and power on again, N200 went back to the old dead
condition again. It looks like the firmware was not permanently burned into
the device EEPROM as it is supposed so. 

 

I may have missed one step or two. Any suggestions?

 

Thanks,

 

Chun

 

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

[USRP-users] Advise on how to modifying HDL design E310 to add custom blocks

2017-09-21 Thread Brais Ares via USRP-users 
Hello,

We want to add some blocks to HDL design in E310 device. We followed the
instructions to build Vivado project and it worked okay.

Thing is the built design when opened in Vivado looks this way
 ...
where design sources hierarchy is kind of complex. I was expecting a top
module or at least not that much sources.

Is there no way to see the design as a block design (like in a typical
Vivado workflow)?

Adding just a few filters to this design implies reverse-engineering what
is going on in most of these source files...

​Any advice in how to proceed/start is appreciated.
Regards,
Brais.​
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Phase jumps in USRP B210 with GPSDO

2017-09-21 Thread Marcus D. Leech via USRP-users 
You talk about board-mounted GPSDOs in each of your B210s, but then talk
about using an Octoclock-G. 

In the Octoclock-G example, you are explicitly selecting "external" for
your refclock and time source? 

It is fully-expected that no two GPSDOs will precisely agree on
frequency and phase, and will have some amount of mutual phase-noise. 
Even when fed with the same antenna. 

On 2017-09-21 10:54, Piotr Krysik via USRP-users wrote:

> Hi all,
> 
> I'm trying trying to use multiple USRPs B210 (that have GPSDOs mounted)
> for tasks requiring good phase coherence between the devices (i.e.
> phased antenna array) and there is some problem. In the recorded signal
> I have found abrupt phase jumps that make B210s unusable for performing
> phase coherent tasks (and that generally might be a problem).
> 
> The devices were synchronized with use of Octoclock-G providing PPS and
> 10MHz ref signal. To check phase coherence I used a signal generator
> (generating sinusoid: -40dBm at 690MHz with USRPs tuned to 690.1MHz with
> sample rate 1MHz, PPS and ref signals taken from external ports, version
> of UHD 3.9.2). See the attached picture in which I removed expected
> phase of the sinusoid (recorded with one of the channels) from the phase
> of the recorded signal. In this example phase jumps happen almost
> periodically (about every 10 seconds).
> 
> Now is the funny part: after taking out GPSDO the problem goes away
> (checked with 3 USRPs B210). Hence the very probable theory is that
> GPSDO's interference causes the problem.
> 
> Have you observed this? And more importantly: do you a have solution?
> (Taking GPSDOs out from all our B210s is not one of them as there are
> many valid tasks that require both GPSDOs and good quality of signal
> signal phase measurement. I still have to check if the same thing
> happens without Octoclock-G.)
> 
> (in the next episode: slow start of transmission in USRP B210 :) )
> 
> --
> Best Regards,
> Piotr Krysik
> 
> ___
> 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] Testing with single B200

2017-09-21 Thread Kevin McQuiggin via USRP-users 
Hi Rensi:

Fantastic that you have your B200 working!

Packet reception is more complex.  The best place to start is at gnuradio.org 
 with their quite detailed tutorials.  There is an 
example showing packet transmission and reception, as I recall.  There are also 
pre-written packet processing blocks, but I haven’t used them.

I would also suggest subscribing to the discuss-gnuradio mailing list.  
Directions are on the gnuradio.org  site.

Expect to take a few weeks at least for reading/learning, especially if you 
have no previous SDR experience.

If you don’t have experience in this area, then there is an excellent book 
called “The Scientist and Engineer's Guide to
Digital Signal Processing” by Steven Smith.  It is free and available online at:

http://dspguide.com/ 

I liked it so much that I bought a hardcopy, and several years in I still refer 
to the book for background information.

Good luck as you start this fun journey!  I started from "ground zero" myself a 
few years ago.

Kevin

> On Sep 21, 2017, at 1:43 AM, Rensi Mathew  wrote:
> 
> Hi Kevin
> 
> I am able to receive FM signals.  It was not using the und_fft.grc but an 
> WBFM receive grc.
> 
> Now I need to receive packets. I am thinking how to go about it?
> 
> Will there be any damage to the USRP if I try to receive using any other 
> antenna, I mean FM signal using 850-6500 MHz antenna?
> 
> Thanking you
> 
> Rensi
> 
> 
> 
> 
> On Tuesday, September 19, 2017 7:27 PM, Kevin McQuiggin  
> wrote:
> 
> 
> Hi Rensi:
> 
> Well it looks like your device is being found.  You should be able to run 
> uhd_fft as such:
> 
>   uhd_fft -f 10350
> 
> This will centre the display on 103.5 MHz.  If you have FM band broadcasters 
> in your region then you should see spikes on the fft display.
> 
> Give this a try and let me and the list know what you see.
> 
> Kevin
> 
> 
>> On Sep 19, 2017, at 2:48 AM, Rensi Mathew > > wrote:
>> 
>> 
>> Hi Kevin
>> 
>> When I try uhd_probe_devices, it is showing serial number and device B200.
>> 
>> My machine is Intel i5-2400CPU @ 3.10 GHz
>> The OS is Ubuntu 16.04
>> 
>> I have installed GNU radio Companion on this.
>> 
>> I will loook into the utility and reply.
>> 
>> Thanking you
>> 
>> Rensi
>> 
>> 
>> On Monday, September 18, 2017 9:09 PM, Kevin McQuiggin > > wrote:
>> 
>> 
>> Hi Renaissance:
>> 
>> Your B200 isn't being found by your computer.  Try the usrp_probe utility, I 
>> forget the exact name but it is in the same directory/folder as uhd_fft.
>> 
>> The USB cable can sometimes be problematic as it has to be high quality, 
>> some cheap cables don't work as they are noisy or have poor connections.
>> 
>> What type of computer and OS are you using?  On Windows there are sometimes 
>> problems with the USB drivers.
>> 
>> Don't worry about the eeprom at all, get the base unit working first.
>> 
>> Let us know how you make out with the probe.
>> 
>> Kevin
>> Sent from my iPhone
>> 
>> On Sep 18, 2017, at 03:54, Rensi Mathew > > wrote:
>> 
>>> Hi Kevin
>>> 
>>> when I try to run uhd_fft, I get the error
>>> 
>>> RuntimeError: LookupError: KeyError: No devices found for ->
>>> Empty Device Address
>>> 
>>> How can I assign a device address?
>>> 
>>> I tried  ./usrp_burn_mb_eeprom --args=addr --values="192.168.10.2" but it 
>>> is not working.
>>> 
>>> Pl do help.
>>> Thanking you
>>> 
>>> Rensi
>>> 
>>> 
>>> On Friday, September 15, 2017 9:12 PM, Kevin McQuiggin >> > wrote:
>>> 
>>> 
>>> Hi Rensi:
>>> 
>>> I’d suggest using the UHD utility programs that come with the B200.  There 
>>> is a spectrum analyzer application, called uhd_fft, and a simple radio 
>>> receiver that can, for example, be used to test your unit with local 
>>> broadcast stations in the FM band.  You’ll need a small antenna for one of 
>>> the SMA connectors.  If you don’t have a proper antenna or connector, you 
>>> could simply stick a short piece of wire into the SMA connector for testing.
>>> 
>>> For transmitting, an antenna is more critical as you shouldn’t really 
>>> transmit into an unconnected or mismatched antenna.  I’d suggest looking 
>>> again at the utilities provided with either the B200 or gnuradio.  You can 
>>> build a simple transmitter and use an “FM band” broadcast radio to receive 
>>> the transmissions from your USRP.
>>> 
>>> I would also suggest going to the gnuradio.org  web 
>>> site and working through the tutorial series.  This will help you get 
>>> started!
>>> 
>>> Kevin
>>> 
>>> 
 On Sep 15, 2017, at 3:27 AM, Rensi Mathew via USRP-users 
 > wrote:
 
 Hi all
 
 I have a single B200 with me

[USRP-users] Phase jumps in USRP B210 with GPSDO

2017-09-21 Thread Piotr Krysik via USRP-users 
Hi all,

I'm trying trying to use multiple USRPs B210 (that have GPSDOs mounted)
for tasks requiring good phase coherence between the devices (i.e.
phased antenna array) and there is some problem. In the recorded signal
I have found abrupt phase jumps that make B210s unusable for performing
phase coherent tasks (and that generally might be a problem).

The devices were synchronized with use of Octoclock-G providing PPS and
10MHz ref signal. To check phase coherence I used a signal generator
(generating sinusoid: -40dBm at 690MHz with USRPs tuned to 690.1MHz with
sample rate 1MHz, PPS and ref signals taken from external ports, version
of UHD 3.9.2). See the attached picture in which I removed expected
phase of the sinusoid (recorded with one of the channels) from the phase
of the recorded signal. In this example phase jumps happen almost
periodically (about every 10 seconds).

Now is the funny part: after taking out GPSDO the problem goes away
(checked with 3 USRPs B210). Hence the very probable theory is that
GPSDO's interference causes the problem.

Have you observed this? And more importantly: do you a have solution?
(Taking GPSDOs out from all our B210s is not one of them as there are
many valid tasks that require both GPSDOs and good quality of signal
signal phase measurement. I still have to check if the same thing
happens without Octoclock-G.)

(in the next episode: slow start of transmission in USRP B210 :) )

--
Best Regards,
Piotr Krysik

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

[USRP-users] creating rx_stream multiple times throws assertion error.

2017-09-21 Thread olivani via USRP-users 
Hi ,

I have a requirement to toggle between channels and collect data for every
10 seconds using E310.


I first specify subdevice A:A and create a rx_stream

collect data and then set subdevice A:B and try to create and rx_stream .

I got an assertion error . So I tried to delete the first rx_stream using
rx_stream.reset().

But that didn't help.

Please let me know if there is any other work around for this,

The other question is

I would like to understand how the data is packaged when I choose (A:A A:B)
can I have more explanation on what this setting does


Thanks and Regards,
Olivani Subbukutty
571-331-2481
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Integration of System Generator custom block into RFNOC

2017-09-21 Thread Marko Jaćović via USRP-users 
Hello,

We are trying to integrate a custom module into RFNOC from Xilinx System
Generator. Has anyone determined the best design flow for this process?

We have exported a simple SysGen design (based on a digital gain block) as
a synthesized checkpoint, but have been unable to connect the design into
the vivado project used by the uhd_image_builder.py script.

To create the Vivado project we executed the uhd_image_builder.py script
with commands from the RFNOC Getting Started tutorial, cancelled the
bitstream generation, and saved the project. We cancelled the bitstream
generation because the script would cause the generation to run to
completion (including Vivado exiting) and we would be unable to save the
project.

Ultimately we would like to repeat the design process for larger SysGen
models, so we would like to determine the process without converting the
model to Verilog and following the RFNOC OOT Module method.

Thank you for your help.

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