Hi all,
Yesterday I had a problem with configuring GPIO pins in USRP X310. I
wanted to send signal in bursts to get pulsed transmission and to turn
on GPIO pin when transmitting, but what I did didn't work correctly. I
received very good advices from Nate Temple on IRC together with custom
version
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 c
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 n
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 exp
W dniu 21.09.2017 o 21:06, Marcus D. Leech via USRP-users pisze:
> 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 differ
Hi Sylvain,
W dniu 22.09.2017 o 11:44, Sylvain Munaut pisze:
> Hi Piotr,
>
>
> And do you set both the Clock and Time source to the external ones
> when using it in that configuration ?
I think I have written this at least twice before. I will try again to
describe it again as clear as I can. Reci
Hi all,
I'm currently trying to find out how much USRPs B210 are capable of
doing in different tasks.
One of these tasks is transmission of burst with use of UHD's burst api.
To access it I have implemented a GNU Radio app that uses tx_time and
packet_len tags.
Particularly the application was co
ansmit anything.
> This solution is a tradeoff: On the pro side the stop-and-go
> transients will go away, while on the con side you won't get a
> perfectly zero RF output when you feed IQ zeros (e.g., because of
> carrier leakage and other RF effects).
>
> Best,
> Dario
Hi all,
For comparison: screenshot of much more "civilized" behavior of USRP
X310 in the same situation.
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 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
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
> B21
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 o
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.
>
> Perha
W dniu 06.10.2017 o 23:22, Marcus D. Leech via USRP-users pisze:
> 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
W dniu 09.10.2017 o 09:36, Piotr Krysik via USRP-users pisze:
> One thing that helped was replacing one of the USRP B210 in the pair
> with another one.
Hi,
I checked everything again and I found out that after replacing one of
my 10MHz ref SMA cable the phase difference between any d
W dniu 09.10.2017 o 10:46, Piotr Krysik via USRP-users pisze:
> W dniu 09.10.2017 o 09:36, Piotr Krysik via USRP-users pisze:
>> One thing that helped was replacing one of the USRP B210 in the pair
>> with another one.
> Hi,
>
> I checked everything again and I found out
Hi all,
After discussion on IRC and few questions (by Brian Padalino and Marcus
D. Leech), that made me not so sure about how I made the measurement, I
found the reason for frequency offset.
It wasn't fault of USRP B210 or broken cable providing 10MHz reference
signal. The issue was a bit more co
Hi all,
I'm prepared a basic GNU Radio flow-graph that does simultaneous
transmission and reception (see the attachment). For USRP X310 and RFNOC
UHD (version above 3.10.x) soon after starting the flow-graph there is a
lot of buffer underflows (even for low sample rate like 1MS/s). For
pre-RFNOC U
W dniu 22.10.2017 o 12:04, Piotr Krysik via USRP-users pisze:
> Hi all,
>
> I'm prepared a basic GNU Radio flow-graph that does simultaneous
> transmission and reception (see the attachment). For USRP X310 and RFNOC
> UHD (version above 3.10.x) soon after starting the flow-gr
Dear list,
Little update on transmitting bursts and simultaneous receiving with
USRP B210. When I connect anything that has some path between TX/RX SMA
port's body and inner female sleeve contact (like 3dB attenuator or even
my finger) the output signal starts to look ok. I don't know what is
caus
W dniu 13.11.2017 o 11:36, Piotr Krysik via USRP-users pisze:
> Dear list,
>
> Little update on transmitting bursts and simultaneous receiving with
> USRP B210. When I connect anything that has some path between TX/RX SMA
> port's body and inner female sleeve contact (like 3d
Hi Hideyuki,
Our students were working (with my help) on synchronizing two USRPs B210
with use of Octoclock-G.
To make your code work without any race-conditions I would add a loop
that waits for pps edge before your adjustment code, like this:
```
time_last_pps = self.uhd_usrp_source_0.get_time
dniu 23.01.2018 o 19:11, Martin Braun via USRP-users pisze:
> On Thu, Jan 18, 2018 at 10:34:14AM +0100, Piotr Krysik via USRP-users wrote:
>> Hi Hideyuki,
>>
>> Our students were working (with my help) on synchronizing two USRPs B210
>> with use of Octoclock-G.
>&g
W dniu 22.02.2018 o 23:37, Marcus D. Leech via USRP-users pisze:
> On 02/22/2018 09:15 AM, Piotr Krysik via USRP-users wrote:
>> Hi all,
>>
>> There was a thread on this topic started by Hideyuki Matsunaga that
>> didn't resolve this question.
>>
>> I w
W dniu 24.02.2018 o 23:10, Marcus D. Leech via USRP-users pisze:
> On 02/24/2018 04:27 PM, Piotr Krysik via USRP-users wrote:
>> Hi Marcus,
>>
>> Ad.A I doubted it as the time reported by both USRPs at the end of
>> synchronization function is about ~0.005 s. Anyway
W dniu 25.02.2018 o 11:16, Piotr Krysik via USRP-users pisze:
> W dniu 24.02.2018 o 23:10, Marcus D. Leech via USRP-users pisze:
>>
>> What if you use the time-stamps on the streams to time-align, and THEN
>> cross-correlate?
>>
>> Remember that multi-usrp do
W dniu 25.02.2018 o 20:08, Marcus D. Leech via USRP-users pisze:
> OK, so (and apologies if this was in your previous data) what is the
> average magnitude of the time discrepancy?
Usually it was about few hundreds us (random). I will try to perform
more measurements.
_
W dniu 26.02.2018 o 11:29, Piotr Krysik via USRP-users pisze:
> W dniu 25.02.2018 o 20:08, Marcus D. Leech via USRP-users pisze:
>> OK, so (and apologies if this was in your previous data) what is the
>> average magnitude of the time discrepancy?
> Usually it was about few h
W dniu 26.02.2018 o 12:43, Piotr Krysik via USRP-users pisze:
> W dniu 26.02.2018 o 11:29, Piotr Krysik via USRP-users pisze:
>> W dniu 25.02.2018 o 20:08, Marcus D. Leech via USRP-users pisze:
>>> OK, so (and apologies if this was in your previous data) what is the
>>&g
W dniu 26.02.2018 o 17:22, Marcus D. Leech via USRP-users pisze:
> On 02/26/2018 09:16 AM, Piotr Krysik via USRP-users wrote:
>> W dniu 26.02.2018 o 12:43, Piotr Krysik via USRP-users pisze:
>>> W dniu 26.02.2018 o 11:29, Piotr Krysik via USRP-users pisze:
>>>> W dni
Hi Hideyuki,
For the solution look at the end of "Is it possible to time synchronize
multiple USRPs B210?" thread.
I attached there a working example for two USRPs B210.
--
Best Regards,
Piotr Krysik
___
USRP-users mailing list
USRP-users@lists.ettus.c
W dniu 26.02.2018 o 19:44, Marcus D. Leech via USRP-users pisze:
> On 02/26/2018 01:36 PM, Piotr Krysik via USRP-users wrote:
>>
>> It's hard for me to understand why only one of the devices changes the
>> master clock rate at that moment. This seems a bit arbitrary. It w
Hello everyone,
I'm considering to create virtual SDR device based on UHD (as libuhd
module) and virtual radio channel (probably a GNU Radio based program).
The main aim is to enable (at least partial) testing of programs using
without need to run actual hardware (i.e. to run base transceiver
stat
> this project open source? I would find a tool like this very valuable.
>
> On Thu, Nov 8, 2018 at 10:48 AM Piotr Krysik via USRP-users
> mailto:usrp-users@lists.ettus.com>> wrote:
>
> Hello everyone,
>
> I'm considering to create virtual SDR device based on
Hi,
No, it's not. Each of your UBX-160 has one Rx chain.
BTW somehow it is common confusion that Tx/Rx and Rx2 ports can be used
to receive signals simultaneously. I have to explain this even to people
with professor degree in electronic engineering, that behind these ports
there is one Rx chain
r the 4 rx are fixed?
>
> Thank you very much in advance!
>
> Best regards,
>
> Maria Jesus
>
>
> On 13/11/2018 12:34, Piotr Krysik via USRP-users wrote:
>> Hi,
>>
>> No, it's not. Each of your UBX-160 has one Rx chain.
>>
>> BTW somehow
Hello everyone,
TwinRXes requires special treatment when setting frequency in order to
keep co-channel phase differences across multiple executions of a
program communicating with USRP.
What exactly 'treatment' I mean can be seen for example here:
https://github.com/EttusResearch/gr-doa/blob/mast
Hi Ali,
The daughterboards have their own clock generators, but they are not
exactly 'independent'. At least they don't have to be, as they share the
same reference clock. Look at the block diagram:
https://kb.ettus.com/images/9/9d/USRP_N310_N300_DB_Schematic.pdf
and "Ref Clock" block. I don't h
W dniu 12.03.2019 o 17:49, Patscheider, Dominik via USRP-users pisze:
>
> Hello ,
>
>
>
> For a Radar I´m transmitting and receiving with the USRP X310 samples
> on different frequency steps.
>
>
>
> For instance, after 4 frames I´m coming back to the first center freq
> and continue this a few
Hi Dominik
W dniu 18.03.2019 o 10:49, Patscheider, Dominik pisze:
> Hi Piotr Krysik,
>
> I wanted to achieve an stepped OFDM Radar.
> To increase the baseband for the radar, I´m splitting the subcarrier and
> transmit them on four center frequencies.
> Thus it sends the first symbols on f0 (wi
W dniu 21.03.2019 o 10:58, Diogo Botelho Ribeiro Marinho via USRP-users
pisze:
>
> I am using N310 and i would like to send my questions to the forum.
>
>
>
> So far i am not able to do it.
>
>
>
>
Hi Diogo,
I beg to disagree. From my perspective it looks that you are able to
send posts to the
it.
So it seems the strange behavior of phase in signal coming from TwinRXes
might be a result of a bug that Nate was informing about.
--
Best Regards,
Piotr Krysik
W dniu 13.03.2019 o 14:48, Piotr Krysik via USRP-users pisze:
> Hello everyone,
>
> TwinRXes requires special treatment when
Hi all,
I'm trying to do calibration of phase offsets between TwinRX channels.
Configuration of X310 is following: two TwinRX'es, all sharing LOs from
fist channel of the second TwinRX.
The same signal is fed to all TwinRX channels through a RF splitter.
What is expected is some additional grou
W dniu 03.04.2019 o 10:34, Piotr Krysik via USRP-users pisze:
> Hi all,
>
> I'm trying to do calibration of phase offsets between TwinRX channels.
>
> Configuration of X310 is following: two TwinRX'es, all sharing LOs from
> fist channel of the second TwinRX.
>
Hi Fabian,
W dniu 03.04.2019 o 11:05, Fabian Schwartau via USRP-users pisze:
> Hi Piotr,
>
> we once had a very similar issue. But we also saw this on the same
> frequency when switching between frequencies. Can you try this as
> well? Just switch forth and back between two frequencies and just pl
is,
> as all LOs are driven from a common 200 MHz reference clock.
>
Do you mean TwinRXes might have similar initial phase reset capability
that UBXes and SBXes have?
--
Best Regards,
Piotr Krysik
> Best regards,
> Fabian
>
> Am 03.04.2019 um 12:05 schrieb Piotr Krysik via USR
To answer my own question:
https://github.com/EttusResearch/uhd/blob/master/CHANGELOG#L226
it seems the answer is yes.
--
Piotr Krysik
W dniu 03.04.2019 o 12:34, Piotr Krysik via USRP-users pisze:
> Hi,
>
> W dniu 03.04.2019 o 12:15, Fabian Schwartau via USRP-users pisze:
>> (
gards,
> Fabian
>
> Am 03.04.2019 um 12:05 schrieb Piotr Krysik via USRP-users:
>> Hi Fabian,
>>
>> W dniu 03.04.2019 o 11:05, Fabian Schwartau via USRP-users pisze:
>>> Hi Piotr,
>>>
>>> we once had a very similar issue. But we also saw this
Hi all,
I looked at this thread and it reminded me of something.
Once we purchased few X310 with UBX160 daughter-boards.
One of them had some frequency offset on Tx channel, that decreased over
time it was running, but very slowly.
The daughter-board was then replaced by National Intruments (af
unch for the info!
>
>
> Mike
>
>
> On 04/08/2019 09:56 AM, Piotr Krysik via USRP-users wrote:
>> Hi all,
>>
>> I looked at this thread and it reminded me of something.
>>
>> Once we purchased few X310 with UBX160 daughter-boards.
>>
>> One of
ettings, it is possible to also achive this,
> >as all LOs are driven from a common 200 MHz reference clock.
> >
> >Best regards,
> >Fabian
> >
> >Am 03.04.2019 um 12:05 schrieb Piotr Krysik via USRP-users:
> >>Hi Fabian,
>
Hi Nicola,
I just had exactly the same issue with UHD 3.14.0.0-72. Upgrading to
full 3.14 release of UHD (top of UHD-3.14 branch) solved the issue for me.
Best Regards,
Piotr Krysik
W dniu 04.02.2019 o 14:42, Michailow, Nicola via USRP-users pisze:
>
> Hi,
>
>
>
> I am trying to connect a USRP
Hello all,
I'm trying to implement better synchronization for SDR base GSM mobile
station (wiki of the project:
https://osmocom.org/projects/osmocom-bb-sdr-phy/wiki).
Currently the mobile station computes clock offset and applies
correction in software to a fractional resampler, in order to achie
W dniu 22.04.2019 o 18:17, Sylvain Munaut pisze:
> Hi Piotr,
>
> The main issue is that the AUX DAC output swing is between 0.5v and 1V
> (i.e. VDD_GPO-0.3v).
> That's not the right range at all to control the VCXO meaningfully.
>
> Cheers,
>
> Sylvain
>
Thanks Sylvain for the answer. It'
Hi all,
I have the same issue. I've checked everything in different computer
(disk with particular Ubuntu 16.04 installation, PCIexpress card and
PCIe cable) and everything worked fine.
What was left was that caused the issue was particular
motherboard+processor. I don't know if it is just this o
e bridge sold by Broadcom. I don't know yet if it has anything to do
with USRP connection.
Best Regards,
Piotr Krysik
W dniu 23.07.2019 o 11:26, Piotr Krysik via USRP-users pisze:
> Hi all,
>
> I have the same issue. I've checked everything in different computer
> (disk with p
56 matches
Mail list logo
