Hi Rodolphe,
> I am completely lost.
Yep, USB does that to you, occasionally...
So, anyways, probably not at all your fault. If you can, make sure
you've got the latest firmware for your laptop.
Personally, I'm kinda lazy, so I prefer to first check whether there's
things that are easy to updat
Hi Damon,
sorry, that wasn't my intention :( But let me make it better!
My current guess is that UHD's DPDK transport gets confused and tries to
use the wrong network card. Luckily, we can try to work around that:
uhd_find_devices --args=use_dpdk=1,addr=192.168.60.2,dpdk_mac=XYZ
where XYZ would
Hi Lukas,
Taking this off the list for a bit...
- On the LO sync, all I mean is the you will need to use a tune request
with the RF policy not NONE and use timed commands - just like for the DSP
freq. Does that make sense?
- The reason that I think that my original methodology for mea
Hi Rob,
That's a good point and I thought about this very early on but figures it would not matter because the phase of the "Tx signal source" is just constant.
In terms of phase we could think of it as "phase_we_want_to_measure + phase_of_tx_source". But since phase_of_tx_source does not c
Hi Rob,
Thanks again so much for reproducing the setup.
Based on Cases 1-4 this is consistent which what I get and it really feels good that you are able to reproduce it.
I have been wrapping my head around WHY can happen for TX/RX but not for TX/TX or RX/RX. It's really hard to imagine t
OK. Thinking about it a little more, I think that perhaps the tx-to-rx
phase measurement methodology was flawed. So, maybe this is not any
issue. I changed the Python (new version attached) to send the gnuradio Tx
signal source (which also drives Tx0 and Tx1) to one input of the
multiply_conjuga
Hi Marcus,
Thank you for your reply. Since you foreget to copy the email to me, I have
to reply from my last email.
dpdk_ipv4 is set to 192.168.60.1/24, the ip address of port 1 of X310 is
set to 192.168.60.2.
dpdk_ipv4 = 192.168.60.1/24
Best regards,
Damon
guowang qiu 于2020年3月17日周二 上午3:03写道：
On 03/20/2020 08:08 AM, Carmichael, Ryan via USRP-users wrote:
So, interestingly, that does not work. Around ping –s 8100 it stops
working.
Sounds like this may either be a Linux networking issue or NIC issue
rather than a UHD issue. I will investigate and see what’s happening
there.
Perh
Lukas,
After looking at this a bit, I think that there is indeed an issue. I
think that it is possible to get consistent tx-to-tx phase results and
consistent rx-to-rx phase results, but NOT consistent rx-to-tx phase
results. A few remarks:
- Setup
- 2-channel X310/UBX-160 with two externa
So, investigations so far show you might
1. have a version of libssl that is so old that it tries to use SSL3
(instead of TLS1.0 or later) to talk to the server; rightfully,
files.ettus.com:443 doesn't support that
2. you might per chance have installed a package that overrides
python-requests' de
Hey Basse,
while I can't reproduce, I can verify that there indeed seems to be a
slight problem with the OCSP verification. We'll look into this.
Best regards,
Marcus
On 20.03.20 01:42, Basse Ang wrote:
> hi Marcus,
>
> Thank you for your reply.
>
> this is the output:
>
> Please run:
>
>
So, interestingly, that does not work. Around ping -s 8100 it stops working.
Sounds like this may either be a Linux networking issue or NIC issue rather
than a UHD issue. I will investigate and see what's happening there.
Perhaps this was always an issue even with 3.11 but it wasn't being report
Hello Cinaed,
During the tests I use a USB 3.0 stick that behaves same as the USRP : with
an other computer, both are well recognized as 3.0, but not in the
erroneous machine. I don't think that neither USB stick, neither USRP USB
cable are faulty.
The output for both USB stickand USRP gives is:
13 matches
Mail list logo
