Dear Nicolas,
Many thanks for your reply!
Regarding your question, yes, they need to run simultaneously,
however, both modules (MIMO PHY and Spectrum Sensing) have different
sampling rates.
The MIMO PHY will be LTE-based and it will have its BW configured at
runtime. I plan to support all the LT
Hi people,
In trying to run OsmoTRX (GSM BTS) with a USRP2 but I get lots of
hicups. Can anyone help me check if those cheap ebay GPSDO with PPS and
10MHz output will work with my old USRP2?
--
I'm thinking in buying with one:
https://www.ebay.com/itm/GPS-Receiver-GPSDO-10MHz-1PPS-GPS-Disciplined-
On 01/15/2018 06:23 AM, Rafael Diniz via USRP-users wrote:
Hi people,
In trying to run OsmoTRX (GSM BTS) with a USRP2 but I get lots of
hicups. Can anyone help me check if those cheap ebay GPSDO with PPS and
10MHz output will work with my old USRP2?
--
I'm thinking in buying with one:
https://ww
Hi Anon,
Please disregard my comment before about the Osmocom blocks, I had switched to
the wrong flowgraph.
A normalized gain of .5 on the TwinRX is bit low. The TwinRX has 95dB of
adjustable gain. Around 60-70 dB will usually provide a good SNR with a common
antenna attached.
Regards,
Na
Dne 2018-01-12 07:05, Jakub Rybka via USRP-users napsal:
Hello,
recently I did receive X310 receivers from Ettus. One of these is
exhibiting following error:
-- X300 initialization sequence...
-- Determining maximum frame size... 8000 bytes.
-- Setup basic communication...
-- Loading values f
No worries, thanks for the update! Are there any known good versions to
check out of uhd/gr-ettus in order to get a working version again? I have
tried the most recent master merge into the rfnoc-devel branch already.
-Paul
On Wed, Jan 10, 2018 at 12:46 PM Nicolas Cuervo
wrote:
> Hi Paul,
>
> U
Hi Anon,
Can you try running these tests with a tagged release of UHD, such as
"release_003_010_002_000" instead of the master branch? You may need to
recompiled GNU Radio against this version of UHD. It is important to
download and flash the 3.10.2.0 FPGA image before running the tests.
If 3.10.
Hello Anon,
I can confirm that your issue is due to software and not a hardware issue.
The fix is released on the maint branch and will be out on the master
branch very shortly.
https://github.com/EttusResearch/uhd/commit/f76762c6e9cd7d7e308c589d57cb89
1eda45a4e8
Can you please apply the one char
Koyel,
CHDR is documented on our manual:
http://files.ettus.com/manual/page_rtp.html#rtp_chdr
However, you typically don't need to care about CHDR. Most blocks
connect to the axi_wrapper, which takes care of any RFNoC internals. Can
you tell us more about what you want to do?
-- M
On 01/12/2018
Dmitry,
2x200e6 is extremely hard to maintain from software, and we haven't been
able to sustain such rates ourselves. We are looking into it, but don't
expect any radical improvements any time soon.
However, that explains Us, not Ss. Can you run ifconfig to see if the
NIC is dropping packets?
T
On 01/11/2018 01:38 AM, Дмитрий Михайличенко via USRP-users wrote:
> Hi,
>
> I am trying to understand timestamp tracking in FPGA and noticed one
> possible issue in axi_rate_change.v module .
>
> VITA time in packet headers is counted in ticks of master clock
> frequency, i.e. 200 MHz. For me it
Hello Jakub:
I suspect that there might be a hardware issue here.
Could you please contact us at "supp...@ettus.com", and we can determine if
an RMA is needed.
Thanks.
--Neel Pandeya
On 15 January 2018 at 11:25, Jakub Rybka via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Dne 2018-01
Hi,
Actually I need to send data that accepts data in the form of vectors and
has a 128 point FFT. What I am doing is first using packet resizer before
my block. So could you please tell me if the size variable of packet
resizer is in bytes or number of samples?
Regards,
Koyel
On Tue, Jan 16, 20
13 matches
Mail list logo
