Re: [USRP-users] FOSDEM 2018: SDR Track CfP

[Martin Braun via USRP-users]

My apologies -- the SDR devroom is Sunday the 4th, not Saturday.

Regards,
Martin


On 10/06/2017 10:00 PM, Martin Braun wrote:
> Dear friends and fans of software defined radio and free/open source
> radio topics in general,
> 
> next year's FOSDEM (the free and open source developer's meeting in
> Brussels, Europe) will, once again, feature a  track on Software Defined
> Radio and other radio-related topics.
> Therefore, we invite developers and users from the free software radio
> community to join us for this track and present your talks or demos.
> 
> Software Radio has become an important tool to allow anyone access the
> EM spectrum. Using free software radio libraries and applications and
> cheap  hardware, anyone can now start hacking on wireless
> communications, remote sensing, radar or other applications. At FOSDEM,
> we hope to network all these projects and improve collaboration, bring
> new ideas forward and get more people involved.
> 
> The track's web site resides at:
> http://gnuradio.org/redmine/projects/gnuradio/wiki/FOSDEM
> 
> Here, we will publish updates and announcements. The final schedule will
> be available through Pentabarf and the official FOSDEM website.
> 
> ** Submit your presentations
> 
> To suggest a talk, go to https://penta.fosdem.org/submission/FOSDEM18
> and follow the instructions (you need an account, but can use your
> account from last year if you have one). You need to create an 'Event';
> make sure it's in the Software Defined Radio track! Lengths aren't
> fixed, but give a realistic estimate and please don't exceed 30 minutes
> unless you have something special planned (in that case, contact one of
> us). Also, don't forget to include time for Q&A.
> We will typically go for 30-minute slots -- shorter talks, unless
> they're really short, usually tend to screw up the schedule too much.
> 
> You aren't limited to slide presentations, of course. Be creative.
> However, FOSDEM is an open source conference, therefore we ask you to
> stay clear of marketing presentations. We like nitty-gritty
> technical stuff.
> 
> Here's a list of topics that will most likely be included:
> - SDR Frameworks + Tools
> - Wireless security
> - Radio hardware
> - Ham radio related topics
> - Telecommunications
> - Random fun wireless hacks
> 
> We will reserve time for interactiveness, it won't all be talks.
> 
> ** Important Dates
> 
> FOSDEM is February 3rd and 4th, 2018.
> 
> * December 8th 2017: Submission Deadline
> * December 18th 2017: Announcement of final schedule
> * February 4th 2018: SDR Track (Sunday)
> 
> These dates are not set in stone. However, the least years we were
> always full to the brim with presentations, so if you want to present,
> please make sure to submit your abstracts soon!
> 
> ** Steering Committee
> 
> The track committee consists of:
> * Phil "Crofton" Balister (OpenEmbedded / OpenSDR)
> * Martin "mbr0wn" Braun (GNU Radio)
> * Sylvain "tnt" Munaut (OsmoCom)
> 
> Hope to hear from you soon! And please forward this announcement.
> 
> Martin
> 


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

[USRP-users] FOSDEM 2018: SDR Track CfP

[Martin Braun via USRP-users]

Dear friends and fans of software defined radio and free/open source
radio topics in general,

next year's FOSDEM (the free and open source developer's meeting in
Brussels, Europe) will, once again, feature a  track on Software Defined
Radio and other radio-related topics.
Therefore, we invite developers and users from the free software radio
community to join us for this track and present your talks or demos.

Software Radio has become an important tool to allow anyone access the
EM spectrum. Using free software radio libraries and applications and
cheap  hardware, anyone can now start hacking on wireless
communications, remote sensing, radar or other applications. At FOSDEM,
we hope to network all these projects and improve collaboration, bring
new ideas forward and get more people involved.

The track's web site resides at:
http://gnuradio.org/redmine/projects/gnuradio/wiki/FOSDEM

Here, we will publish updates and announcements. The final schedule will
be available through Pentabarf and the official FOSDEM website.

** Submit your presentations

To suggest a talk, go to https://penta.fosdem.org/submission/FOSDEM18
and follow the instructions (you need an account, but can use your
account from last year if you have one). You need to create an 'Event';
make sure it's in the Software Defined Radio track! Lengths aren't
fixed, but give a realistic estimate and please don't exceed 30 minutes
unless you have something special planned (in that case, contact one of
us). Also, don't forget to include time for Q&A.
We will typically go for 30-minute slots -- shorter talks, unless
they're really short, usually tend to screw up the schedule too much.

You aren't limited to slide presentations, of course. Be creative.
However, FOSDEM is an open source conference, therefore we ask you to
stay clear of marketing presentations. We like nitty-gritty
technical stuff.

Here's a list of topics that will most likely be included:
- SDR Frameworks + Tools
- Wireless security
- Radio hardware
- Ham radio related topics
- Telecommunications
- Random fun wireless hacks

We will reserve time for interactiveness, it won't all be talks.

** Important Dates

FOSDEM is February 3rd and 4th, 2018.

* December 8th 2017: Submission Deadline
* December 18th 2017: Announcement of final schedule
* February 3rd 2018: SDR Track (Saturday)

These dates are not set in stone. However, the least years we were
always full to the brim with presentations, so if you want to present,
please make sure to submit your abstracts soon!

** Steering Committee

The track committee consists of:
* Phil "Crofton" Balister (OpenEmbedded / OpenSDR)
* Martin "mbr0wn" Braun (GNU Radio)
* Sylvain "tnt" Munaut (OsmoCom)

Hope to hear from you soon! And please forward this announcement.

Martin

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

Re: [USRP-users] Trouble Connecting to N210 in VMWare

[Tellrell White via USRP-users]

KenI'm using vmware. Not sure if you used the same client but how exactly did 
you configure your vm to bridged. Also, I used the command to set an alias ip 
to 192.168.10.1 which is in the same subnet as the N210, not sure if thats 
different from the manual approach you're suggesting.
Tellrell  

On Friday, October 6, 2017 10:32 PM, Ken M Erney  
wrote:
 

 What are you using as the VM software client (e.g. VMware, virtual box, etc.). 
I was able to get mine to work but I had to configure my VM eth as "bridged". I 
also set it with a manually configured ip in the same subnet as the N210.
- ken
On Oct 6, 2017 10:23 PM, "Tellrell White via USRP-users" 
 wrote:

Hello Guys. 
I'm currently trying to connect to the N210 using an ubuntu 14.04 virtual 
machine. I've tried the commands uhd_find_devices and also uhd_usrp_probe and 
they both indicate "no devices found". Pinging 192.168.2 comes up empty as 
well. I used the command sudo ip address add 192.168.10.1/255.255.255.0 dev 
eth0 to set the ip of the virtual machine. I'm connected to the internet via 
wi-fi. The version of UHD i'm using is 3.10.2. Any help is greatly appreciated. 

RegardsTellrell

__ _
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] Trouble Connecting to N210 in VMWare

[Ken M Erney via USRP-users]

What are you using as the VM software client (e.g. VMware, virtual box,
etc.). I was able to get mine to work but I had to configure my VM eth as
"bridged". I also set it with a manually configured ip in the same subnet
as the N210.

- ken

On Oct 6, 2017 10:23 PM, "Tellrell White via USRP-users" <
usrp-users@lists.ettus.com> wrote:

Hello Guys.
I'm currently trying to connect to the N210 using an ubuntu 14.04 virtual
machine. I've tried the commands uhd_find_devices and also uhd_usrp_probe
and they both indicate "no devices found". Pinging 192.168.2 comes up empty
as well. I used the command sudo ip address add 192.168.10.1/255.255.255.0
dev eth0 to set the ip of the virtual machine. I'm connected to the
internet via wi-fi. The version of UHD i'm using is 3.10.2. Any help is
greatly appreciated.

Regards
Tellrell

___
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] Trouble Connecting to N210 in VMWare

[Tellrell White via USRP-users]

Hello Guys. 
I'm currently trying to connect to the N210 using an ubuntu 14.04 virtual 
machine. I've tried the commands uhd_find_devices and also uhd_usrp_probe and 
they both indicate "no devices found". Pinging 192.168.2 comes up empty as 
well. I used the command sudo ip address add 192.168.10.1/255.255.255.0 dev 
eth0 to set the ip of the virtual machine. I'm connected to the internet via 
wi-fi. The version of UHD i'm using is 3.10.2. Any help is greatly appreciated. 

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

Re: [USRP-users] Frequency offset between two USRPs B210 synchronized with use of Octoclock-G

[Andrej Rode via USRP-users]

Hi, 

> Questions:
> 1. Have anyone synchronized USRPs B210 up to having constant phase
> offset between the devices?
> 2. If yes - how?

In the UHD tree you find a OOT in tools/gr-usrptest. If
compiled + installed it will provide a tool called
usrp_phasealignment.py.
Using that you can "stress test" phase alignment with retunes and plot/prints 
the results.
For the SBX you should get phase alignment across retunes/power cycling using 
that and a common 10 MHz Ref & 1PPS signal.

Under the hood it uses a reconfigurable GNU Radio flowgraph, so it also
should show if this works through GR API.

Cheers
Andrej
-- 
Andrej Rode
GPG Key: 750B CBBB 4A75 811A 4D5F 03ED 5C23 7FB8 9A7D A2AA


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

Re: [USRP-users] X300 continuous overflow errors

[Perelman, Nathan via USRP-users]

I’m still seeing the issue with UHD 3.10.2.0. This is with the stock FPGA image.

 

 

From: Neel Pandeya [mailto:neel.pand...@ettus.com] 
Sent: Thursday, July 20, 2017 2:09 PM
To: Perelman, Nathan 
Cc: usrp-users 
Subject: Re: [USRP-users] X300 continuous overflow errors

 

Hello Nathan:

You might to take a look at the fast-frequency hopping demo code, which does 
what you're doing, and uses the X300/X310 and TwinRX.

Are you using the stock FPGA image, or did you modify the FPGA code and make a 
custom FPGA image?

 

I would also suggest trying your program with UHD 3.10.2.0, and seeing if the 
problem persists. The release was tagged yesterday, and the final release will 
be made very soon (link below).

http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-July/025717.html

Please let me know if you are able to make any further progress.

--​Neel Pandeya



 

On 21 April 2017 at 14:18, Perelman, Nathan via USRP-users 
mailto:usrp-users@lists.ettus.com> > wrote:

I’m using UHD 3.10.1.1 and a TwinRX in an X310. My application does many 
repeated captures, some very short (~20 samples), some 2-5 seconds long. 
After many captures (5-10 minutes, all on the same channel), I am seeing it get 
into a state where every capture errors out with an overflow (error 8) after 
2-5 thousand samples have been received. This is with reusing the same RX 
Streamer for every capture. Any ideas for what might be causing this or how to 
debug?

-Nathan


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

 



smime.p7s
Description: S/MIME cryptographic signature
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Frequency offset between two USRPs B210 synchronized with use of Octoclock-G

[john Shields via USRP-users]

On 06/10/17 19:47, Piotr Krysik via USRP-users wrote:

W dniu 06.10.2017 o 21:33, Piotr Krysik via USRP-users pisze:

Hello everyone,

I synchronized two USRPs B210 with use of Octoclock-G and the attached
gnuradio-companion flowgraph.

I've connected signal generator generating sinusoid to both devices (it
was on frequency 694.5MHz while USRPs were tuned to 694.3MHz, signal
power was about -40dBm). What I would expect is to see constant phase
offset between signals received by both USRPs (perhaps changing slightly
with temperature etc.). However what I see is constant changes of phase
that corresponds to frequency offset between two devices. Moreover this
frequency offset changes significantly from one execution of a flowgraph
to another (look at the image):

relative phase of two B210's


Missing image of phase offsets in the attachment.

Best Regards,
Piotr Krysik




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


Hi Piotr,

    While I have a slightly different h/w configuration 
(2xN200, one GPSDO connected through MIMO cable (i.e. I use slightly 
different time/clock sources; and 2 SBXs) and while I have modified the 
Python code to use  timed_commands per the ettus sync page , I have not 
been able to get a consistent relative phase offset between the devices 
on successive GRC runs. I have been struggling for quite a while - 
hopefully, you will get a resolution quickly and I believe it might also 
fix my problem!



 Kind Regards,


 John

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

Re: [USRP-users] Frequency offset between two USRPs B210 synchronized with use of Octoclock-G

[Marcus D. Leech via USRP-users]

On 10/06/2017 03:47 PM, Piotr Krysik via USRP-users wrote:

W dniu 06.10.2017 o 21:33, Piotr Krysik via USRP-users pisze:

Hello everyone,

I synchronized two USRPs B210 with use of Octoclock-G and the attached
gnuradio-companion flowgraph.

I've connected signal generator generating sinusoid to both devices (it
was on frequency 694.5MHz while USRPs were tuned to 694.3MHz, signal
power was about -40dBm). What I would expect is to see constant phase
offset between signals received by both USRPs (perhaps changing slightly
with temperature etc.). However what I see is constant changes of phase
that corresponds to frequency offset between two devices. Moreover this
frequency offset changes significantly from one execution of a flowgraph
to another (look at the image):

relative phase of two B210's


Missing image of phase offsets in the attachment.

Best Regards,
Piotr Krysik


Try disabling automatic DC-offset and I/Q correction.  I've run into 
this before--since the DC offset and I/Q correction logic is somewhat 
stochastic, you would
  expect precise phase-measurements between two devices to wander 
around a bit with respect to one another.




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

Re: [USRP-users] Frequency offset between two USRPs B210 synchronized with use of Octoclock-G

[Marcus D. Leech via USRP-users]

On 10/06/2017 03:33 PM, Piotr Krysik via USRP-users wrote:

Hello everyone,

I synchronized two USRPs B210 with use of Octoclock-G and the attached
gnuradio-companion flowgraph.

I've connected signal generator generating sinusoid to both devices (it
was on frequency 694.5MHz while USRPs were tuned to 694.3MHz, signal
power was about -40dBm). What I would expect is to see constant phase
offset between signals received by both USRPs (perhaps changing slightly
with temperature etc.). However what I see is constant changes of phase
that corresponds to frequency offset between two devices. Moreover this
frequency offset changes significantly from one execution of a flowgraph
to another (look at the image):

relative phase of two B210's

What is on this image is not normal - i.e. much better phase offsets I
can get on two synced RTL-SDR dongles, working under patched driver.

Questions:
1. Have anyone synchronized USRPs B210 up to having constant phase
offset between the devices?
2. If yes - how?

Best Regards,
Piotr Krysik

One thing to note is that UHD *DOES NOT* do timestamp alignment across 
multiple UHD container objects, so you can expect there to be a random 
phase-offset between the two halves in this scenario every time you run.




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

Re: [USRP-users] Fwd: Re: USRP's B210 sluggish start of transmission

[Piotr Krysik via USRP-users]

W dniu 06.10.2017 o 17:48, Nick Foster pisze:
> This is especially baffling to me, because I recall that the
> SKY13335-187LF switches used in B210 must be isolated from DC on all
> RF ports. But they are! The only components connected to the SMA
> connectors are a series 470pF capacitor.
>
> Perhaps the problem is exacerbated by poor impedance matching rather
> than by lack of a DC path. If reflected power was causing the problem
> I'd expect lowering the transmit gain to affect your results. Could
> you try that for me?
>
>
Nick,

There is no difference. Even for transmit gain 0 the problem persists.

I have a feeling that the answer to the question might be easier to find
if we know what is state of TX/RX switches before start of burst and
after it.

Best Regards,
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] Frequency offset between two USRPs B210 synchronized with use of Octoclock-G

[Piotr Krysik via USRP-users]

W dniu 06.10.2017 o 21:33, Piotr Krysik via USRP-users pisze:
> Hello everyone,
>
> I synchronized two USRPs B210 with use of Octoclock-G and the attached
> gnuradio-companion flowgraph.
>
> I've connected signal generator generating sinusoid to both devices (it
> was on frequency 694.5MHz while USRPs were tuned to 694.3MHz, signal
> power was about -40dBm). What I would expect is to see constant phase
> offset between signals received by both USRPs (perhaps changing slightly
> with temperature etc.). However what I see is constant changes of phase
> that corresponds to frequency offset between two devices. Moreover this
> frequency offset changes significantly from one execution of a flowgraph
> to another (look at the image):
>
> relative phase of two B210's
>
Missing image of phase offsets in the attachment.

Best Regards,
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] Error in RFNoC grc with OOT module

[John Medrano via USRP-users]

Hello,

We found two errors in the file:

1. samp_rate parameter is not defined.
2. There is an indention error. The lines with "self.$(id).set_arg("spp",
$spp)" should not have leading spaces.

Thanks,
John

On Thu, Oct 5, 2017 at 11:38 AM, Avila, Jose A via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Thanks for the response and attached is the XML file, also the last commit
> is
>
>
>
>
>
> *commit 23508458f31e8b50264045ee0a34d07c7abc807d Author: Derek Kozel
> > Date:   Thu Jun 29 08:37:14
> 2017 -0700 *
>
> --
> *From:* Nicolas Cuervo 
> *Sent:* Wednesday, October 4, 2017 10:39:43 PM
> *To:* Avila, Jose A
> *Cc:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] Error in RFNoC grc with OOT module
>
> Hello Jose,
>
> this might be an indentation problem at the XML that is located at
> your_oot/grc/your_block.xml. Do you mind sharing with us that file?
>
> Also, I remember seeing this error in earlier versions of the tool, so it
> would be interesting to know if it still happens, and under what
> conditions. Could you please tell us which is the last commit that you are
> pointing to at "gr-ettus"? To check, please go to your gr-ettus repository
> and run:
>
> $ git log
>
> If it is not updated, it is always recommended to update.
>
> Regards,
> -N
>
> On Wed, Oct 4, 2017 at 11:02 PM, Avila, Jose A via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hello we are developing an OOT module following the tutorial, but similar
>> to siggen, but are currently encountering an error that comes up with
>>
>>
>> *./testtwochannel.py*
>>
>> The error that comes up is the following
>>
>>
>>
>>
>> *  File "./testtwochannel.py", line 97
>> self.siggen2ch_twochannelsiggen_0 = Template error:
>> siggen2ch.twochannelsiggen(
>>  ^ SyntaxError: invalid
>> syntax*
>>
>> The file in question is the following:
>>
>>
>> #!/usr/bin/env python2
>> # -*- coding: utf-8 -*-
>> ##
>> # GNU Radio Python Flow Graph
>> # Title: Testtwochannel
>> # Generated: Wed Oct  4 14:35:59 2017
>> ##
>>
>> if __name__ == '__main__':
>> import ctypes
>> import sys
>> if sys.platform.startswith('linux'):
>> try:
>> x11 = ctypes.cdll.LoadLibrary('libX11.so')
>> x11.XInitThreads()
>> except:
>> print "Warning: failed to XInitThreads()"
>>
>> from PyQt4 import Qt
>> from gnuradio import eng_notation
>> from gnuradio import gr
>> from gnuradio import qtgui
>> from gnuradio import uhd
>> from gnuradio.eng_option import eng_option
>> from gnuradio.filter import firdes
>> from optparse import OptionParser
>> import SimpleXMLRPCServer
>> import ettus
>> import siggen2ch
>> import sip
>> import sys
>> import threading
>> from gnuradio import qtgui
>>
>>
>> class testtwochannel(gr.top_block, Qt.QWidget):
>>
>> def __init__(self):
>> gr.top_block.__init__(self, "Testtwochannel")
>> Qt.QWidget.__init__(self)
>> self.setWindowTitle("Testtwochannel")
>> qtgui.util.check_set_qss()
>> try:
>> self.setWindowIcon(Qt.QIcon.fromTheme('gnuradio-grc'))
>> except:
>> pass
>> self.top_scroll_layout = Qt.QVBoxLayout()
>> self.setLayout(self.top_scroll_layout)
>> self.top_scroll = Qt.QScrollArea()
>> self.top_scroll.setFrameStyle(Qt.QFrame.NoFrame)
>> self.top_scroll_layout.addWidget(self.top_scroll)
>> self.top_scroll.setWidgetResizable(True)
>> self.top_widget = Qt.QWidget()
>> self.top_scroll.setWidget(self.top_widget)
>> self.top_layout = Qt.QVBoxLayout(self.top_widget)
>> self.top_grid_layout = Qt.QGridLayout()
>> self.top_layout.addLayout(self.top_grid_layout)
>>
>> self.settings = Qt.QSettings("GNU Radio", "testtwochannel")
>> self.restoreGeometry(self.settings.value("geometry").toByteA
>> rray())
>>
>> ##
>> # Variables
>> ##
>> self.samp_rate = samp_rate = 10e6
>> self.waveform = waveform = "SINE_WAVE"
>> self.ip_addr = ip_addr = "192.168.10.100"
>> self.gain = gain = 1.0
>> self.freq = freq = samp_rate/10
>> self.enable = enable = False
>> self.device3 = device3 = ettus.device3(uhd.device_addr_t(
>> ",".join(('type=e3x0', "")) ))
>> self.ampl_q = ampl_q = 1
>> self.ampl_i = ampl_i = 1
>>
>> ##
>> # Blocks
>> ##
>> self.xmlrpc_server_0 = 
>> SimpleXMLRPCServer.SimpleXMLRPCServer(('0.0.0.0',
>> 8080), allow_none=True)
>> self.xmlrpc_server_0.register_instance(self)
>> self.xmlrpc_server_0_thread = thre

Re: [USRP-users] Fwd: Re: USRP's B210 sluggish start of transmission

[Nick Foster via USRP-users]

Piotr,

This is especially baffling to me, because I recall that the SKY13335-187LF
switches used in B210 must be isolated from DC on all RF ports. But they
are! The only components connected to the SMA connectors are a series 470pF
capacitor.

Perhaps the problem is exacerbated by poor impedance matching rather than
by lack of a DC path. If reflected power was causing the problem I'd expect
lowering the transmit gain to affect your results. Could you try that for
me?

Nick

On Fri, Oct 6, 2017, 1:41 AM Piotr Krysik via USRP-users <
usrp-users@lists.ettus.com> wrote:

> W dniu 27.09.2017 o 07:06, Piotr Krysik via USRP-users pisze:
> > Hi all,
> >
> > I narrowed down when the issue occurs.
> >
> > When using separate sides of B210 for transmitting (i.e. TX/RX port on
> > RF A side) and receiving (i.e. RX2 port on RF B side) everything is fine
> and B210 starts transmitting like i.e. X310.
> >
> >
> > The problem appears when transmitting and receiving on the same side of
> > B210 and it is dependent on what you connect to the TX port. The 300us
> > transition appears if I don't connect anything and measure the TX-RX
> > leakage or when VERT900 antenna from Ettus is connected.
> >
> > I tried also to connect a power splitter to the TX port and an antenna
> > to one of the splitter's ports - with the same result. But as soon as I
> > connected the 30dB attenuator to another port of the splitter, the
> > problem immediately goes away.
> >
> >> The attenuator also has a path (resistive 50 ohms) to groundan
> >> antenna with a small pad on it (say 1 db) will probably work fine as
> well.
> >> Kent Torell
> > So you might be right here Kent that it was the path to the ground in
> the attenuator that
> > changed how the output behaves. It is funny thought that the problem
> > only appears when RX2 port on the same side of B210 is also used :).
> >
> Hi all,
>
> As for my current application transmitting bursts and receiving
> continuous signal with use of all B210 RF ports is not required, I can
> avoid the problem. So I don't have currently motivation to pursue the
> investigation further.
>
> The problem isn't solved though. There are of course applications in
> which it is required to use all RX and TX ports and it is convenient to
> transmit burst. If someone needs it I can provide the codes that I used
> for tests (they are not secret, I just don't want to lose time on
> preparing them in case there is no such person). What I have is a GNU
> Radio block that adds tx_time and length tags to a signal, with user
> defined burst length and gap length. From the tagged stream UHD sink is
> able to produce bursts instead of continuous signal. I have also a GRC
> application that presents the problem.
>
> 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] Fwd: Re: USRP's B210 sluggish start of transmission

[Piotr Krysik via USRP-users]

W dniu 27.09.2017 o 07:06, Piotr Krysik via USRP-users pisze:
> Hi all,
>
> I narrowed down when the issue occurs.
>
> When using separate sides of B210 for transmitting (i.e. TX/RX port on
> RF A side) and receiving (i.e. RX2 port on RF B side) everything is fine and 
> B210 starts transmitting like i.e. X310.
>
>
> The problem appears when transmitting and receiving on the same side of
> B210 and it is dependent on what you connect to the TX port. The 300us
> transition appears if I don't connect anything and measure the TX-RX
> leakage or when VERT900 antenna from Ettus is connected.
>
> I tried also to connect a power splitter to the TX port and an antenna
> to one of the splitter's ports - with the same result. But as soon as I
> connected the 30dB attenuator to another port of the splitter, the
> problem immediately goes away.
>
>> The attenuator also has a path (resistive 50 ohms) to groundan
>> antenna with a small pad on it (say 1 db) will probably work fine as well.
>> Kent Torell
> So you might be right here Kent that it was the path to the ground in the 
> attenuator that
> changed how the output behaves. It is funny thought that the problem
> only appears when RX2 port on the same side of B210 is also used :).
>
Hi all,

As for my current application transmitting bursts and receiving
continuous signal with use of all B210 RF ports is not required, I can
avoid the problem. So I don't have currently motivation to pursue the
investigation further.

The problem isn't solved though. There are of course applications in
which it is required to use all RX and TX ports and it is convenient to
transmit burst. If someone needs it I can provide the codes that I used
for tests (they are not secret, I just don't want to lose time on
preparing them in case there is no such person). What I have is a GNU
Radio block that adds tx_time and length tags to a signal, with user
defined burst length and gap length. From the tagged stream UHD sink is
able to produce bursts instead of continuous signal. I have also a GRC
application that presents the problem.

Best Regards,
Piotr Krysik

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