USRP
products such as X300 series or so.
Regards.
--
Armin Ghani
Research Engineer | Communication Systems Division (CSD)
agh...@cttc.es <mailto:agh...@cttc.es>| +34 93 645 29 08 (2143)
Centre Tecnològic de Telecomunicacions de Catalunya (CTTC)
Av. Carl Friedrich Gauss, 7 - Edifici B4 -
s a bit
difficult for me. I'd like to know if there are any other way to solve
this issue or if you know remote ways to do resetting which is
equivalent to hard reset.
Regards.
--
Armin Ghani
Research Engineer | Communication Systems Division (CSD)
agh...@cttc.es <mailto:agh...
ssuming
at the same frequency reception), I'll have those samples in the RX
stream which is delayed equal to end-to-end propagation delay of USRPs.
If you have any tips/tricks to do it in GRC, I'll be more than thankfull.
Regards.
--
Armin Ghani
Research Engineer | Communication Systems
ssuming
at the same frequency reception), I'll have those samples in the RX
stream which is delayed equal to end-to-end propagation delay of USRPs.
If you have any tips/tricks to do it in GRC, I'll be more than thankfull.
Regards.
--
Armin Ghani
Research Engineer | Communication Systems
channels to 4 (with the
skip_dram arg removed), and drive the two unused TX channels with a
const source 0?
Jonathon
On Fri, Jul 9, 2021 at 11:56 AM Marcus D. Leech
mailto:patchvonbr...@gmail.com>> wrote:
On 07/09/2021 11:54 AM, Armin Ghani wrote:
5Msps
If there's a way
5Msps
On 9/7/21 17:50, Marcus D. Leech wrote:
On 07/09/2021 10:31 AM, Armin Ghani wrote:
Thanks Marcus.
It helped to resolve the error. But UHD consistently prints "L" in
the output.
Would you what DRAM FIFO block actually does?
It's a FIFO between the DUC and the ADC a
Thanks Marcus.
It helped to resolve the error. But UHD consistently prints "L" in the
output.
Would you what DRAM FIFO block actually does?
Regards
On 9/7/21 14:41, Marcus D. Leech wrote:
On 07/09/2021 07:40 AM, Armin Ghani wrote:
Dear community
I've been trying
here is no other solution to do so.
Attached you can find the flowgraph that I run.
Best regards.
--
Armin Ghani
Research Engineer | Communication Systems Division (CSD)
agh...@cttc.es <mailto:agh...@cttc.es>| +34 93 645 29 08 (2143)
Centre Tecnològic de Telecomunicacions de Catalunya
I finally caught the bug, I mistakenly swapped the REF and TRG ports and
one the USRPs couldnt lock to the reference.
Thanks for your support.
On 7/7/21 17:22, Marcus D. Leech wrote:
On 07/07/2021 11:19 AM, Armin Ghani wrote:
I checked the signals at the cable end which attached to the USRP
I checked the signals at the cable end which attached to the USRP input
reference.
And all the cables are the same part number with same cable length. Is
there anything else to check?
On 7/7/21 17:16, Marcus D. Leech wrote:
On 07/07/2021 11:14 AM, Armin Ghani wrote:
I've just checke
I've just checked the reference source for all USRPs, both 10MHz and
1PPS are perfectly distributed on the octoclock output.
10MHz => 3.5V p-p
1PPS => 5V p-p
Regards.
On 7/7/21 16:43, Marcus D. Leech wrote:
On 07/07/2021 10:38 AM, Armin Ghani wrote:
What do you mean by not impl
USRP hardware?
Regards.
On 7/7/21 16:33, Marcus D. Leech wrote:
On 07/07/2021 09:36 AM, Armin Ghani wrote:
Dear USRP and GNURadio Community
I have 3 USRP X310 with two SBX-120 daughterboards installed. each of
USRPs has two dedicated 10GB Interface with host server.
I'm trying
x27;external', 0)
File "/usr/local/lib/python3/dist-packages/gnuradio/uhd/uhd_swig.py",
line 3793, in set_clock_source
return _uhd_swig.usrp_source_sptr_set_clock_source(self, source,
mboard)
RuntimeError: RuntimeError: Reference Clock PLL failed to lock to
external source
13 matches
Mail list logo
