Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Received power changing in sinusoidal manner (Marcus M?ller)
2. Re: Received power changing in sinusoidal manner (Vladica Sark)
3. The transimitter gain of USRP NI-2920 (Zhang, Wenyu)
4. Re: Error using RFNoC OFDM Sync block on E310 (Sergio Cruz Perez)
5. Re: The transimitter gain of USRP NI-2920 (Steven Knudsen)
6. uhd.tune_request always returns 0 (Elvis Angelaccio)
7. Re: uhd.tune_request always returns 0 (Marcus M?ller)
8. Re: uhd.tune_request always returns 0 (Marcus D. Leech)
----------------------------------------------------------------------
Message: 1
Date: Sat, 21 May 2016 21:05:39 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Received power changing in sinusoidal manner
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Vladica,
hm, yes, power before filter eliminates my "oscillator offset changing
with about 450Hz" theory.
Things to try: reduce the gain; maybe you're driving one of the
amplifiers too hard, and it reduces gain due to temperature, then cools
down, increases gain... something that goes through my head right now is
that a nearby 5GHz-band Wifi (802.11a,g,n or 802.11ac) or something else
in that band might be saturating the RX LNA.
One thing you should definitely try is using a cable (I think you're
using antennas now, right?) with attenuators ? this modulation at
roughly 450 Hz (if I'm not mistaken) could me some interference (or its
harmonics) that somehow ends up in the RX signal as modulation; not
totally sure /how/, but that would be one of my next things to
investigate). Though it's not really that likely (PDP typically being
somewhat Gaussian-Bell-Shaped), I'd still not even rule out fading here.
Best regards,
Marcus
On 21.05.2016 17:39, Vladica Sark via USRP-users wrote:
>
> Hi Marcus, Anselm,
>
> These are before the root rised cosine at the receiver. So, directly
> the samples from the uhd.
> The radios are not synced. Run on their own oscillator. Anyway, the
> frequency offset is around 600 Hz, which is not too much. However,
> each symbol is sampled with 4 samples. I tried with 8 times
> oversampling, but the problem still exists. It is maybe worser. Also
> in this case sample rate was 50 MSps, and each symbol represented with
> 8 samples. On Monday I would be able to use heavy artilery - scope and
> signal generator to see what happens. I think that the problem comes
> from the receiver, according to what I remember from the past.
> Just to mention, there is no frequencu offset correction neither
> timing recovery, but with 8x oversampling this should not make problems.
> Best regards'
> Vladica
>
> On May 21, 2016 3:17 PM, "Marcus M?ller" <[email protected]
> <mailto:[email protected]>> wrote:
> >
> > Hi Vladica,
> >
> > no, sorry, never seen that myself; however, I don't have an XCVR2450
> to test.
> >
> > So, what's important to my understanding here: Is the power.jpg,
> frames.jpg taken *before* or after the root raised cosine filter?
> > And: are the USRPs somehow frequency synced, or do they run off
> their own oscillators?
> >
> > Best regards,
> > Marcus
> >
> >
> > On 21.05.2016 14:45, Vladica Sark via USRP-users wrote:
> >>
> >> Hi there,
> >>
> >> I use 2x N210 with 2x XCVR2450 daughter boards and I transmit
> frames at 5785 MHz. The frames are received, but the problem is that
> the power of the received frames varies in sinusoidal manner. The
> scenario is static and the both stations are on 2 meters distance.
> >>
> >> I use 50 MSps with sc8 wire format. The modulation is BPSK and the
> symbols are 4x oversampled and filtered with SRRC at the transmitter
> and at the receiver. The frames burst sent is the same frame repeated.
> >>
> >> In power.jpg the instant power averaged over a short interval is
> shown. The sine modulation can be easily seen.
> >> The frames.jpg shows the instant power of the frames not averaged.
> >> The frame.jpg shows the instant power of one frame not averaged.
> >>
> >> I noticed that from the TX side I have relatively strong (more than
> I would expect) carrier, due to dc bias probably. This is probably not
> the issue.
> >>
> >> Any idea what can it be, or have you seen something similar?
> >>
> >> BR,
> >> Vladica
> >>
> >>
> >> _______________________________________________
> >> USRP-users mailing list
> >> [email protected] <mailto:[email protected]>
> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected] <mailto:[email protected]>
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160521/8ddba6a1/attachment-0001.html>
------------------------------
Message: 2
Date: Sat, 21 May 2016 22:30:14 +0200
From: Vladica Sark <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Received power changing in sinusoidal manner
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Marcus,
In my case, the channel at 5 GHz seems quite clear, regarding the other
transmitters. Regarding the gain, I set it up, in order do have some
decent dynamic range on the ADCs. Anyway, I would try to reduce it.
I would also try with cables. This would be on 2.4 GHz since I have a
couple of 20 dB attenuators up to 3 GHz. Probably can find some for 5
GHz, but lets see what happens on 2.4 GHz.
About the frequency, you are right, it is about 400-600 Hz. I should try
to estimate it a bit more precisely, since I might get some clue.
Anyway, on Monday, I would try a couple of things and then I can also
try with another set of N210s and SBX boards. This would eliminate
hardware issues or defects in the present set of radios.
I would write what I got.
BR,
Vladica
On 21.05.2016 21:05, Marcus M?ller via USRP-users wrote:
> Hi Vladica,
>
> hm, yes, power before filter eliminates my "oscillator offset changing
> with about 450Hz" theory.
> Things to try: reduce the gain; maybe you're driving one of the
> amplifiers too hard, and it reduces gain due to temperature, then cools
> down, increases gain... something that goes through my head right now is
> that a nearby 5GHz-band Wifi (802.11a,g,n or 802.11ac) or something else
> in that band might be saturating the RX LNA.
>
> One thing you should definitely try is using a cable (I think you're
> using antennas now, right?) with attenuators ? this modulation at
> roughly 450 Hz (if I'm not mistaken) could me some interference (or its
> harmonics) that somehow ends up in the RX signal as modulation; not
> totally sure /how/, but that would be one of my next things to
> investigate). Though it's not really that likely (PDP typically being
> somewhat Gaussian-Bell-Shaped), I'd still not even rule out fading here.
>
> Best regards,
> Marcus
>
>
>
> On 21.05.2016 17:39, Vladica Sark via USRP-users wrote:
>>
>> Hi Marcus, Anselm,
>>
>> These are before the root rised cosine at the receiver. So, directly
>> the samples from the uhd.
>> The radios are not synced. Run on their own oscillator. Anyway, the
>> frequency offset is around 600 Hz, which is not too much. However,
>> each symbol is sampled with 4 samples. I tried with 8 times
>> oversampling, but the problem still exists. It is maybe worser. Also
>> in this case sample rate was 50 MSps, and each symbol represented with
>> 8 samples. On Monday I would be able to use heavy artilery - scope and
>> signal generator to see what happens. I think that the problem comes
>> from the receiver, according to what I remember from the past.
>> Just to mention, there is no frequencu offset correction neither
>> timing recovery, but with 8x oversampling this should not make problems.
>> Best regards'
>> Vladica
>>
>> On May 21, 2016 3:17 PM, "Marcus M?ller"
>> <<mailto:[email protected]>[email protected]> wrote:
>> >
>> > Hi Vladica,
>> >
>> > no, sorry, never seen that myself; however, I don't have an XCVR2450
>> to test.
>> >
>> > So, what's important to my understanding here: Is the power.jpg,
>> frames.jpg taken *before* or after the root raised cosine filter?
>> > And: are the USRPs somehow frequency synced, or do they run off
>> their own oscillators?
>> >
>> > Best regards,
>> > Marcus
>> >
>> >
>> > On 21.05.2016 14:45, Vladica Sark via USRP-users wrote:
>> >>
>> >> Hi there,
>> >>
>> >> I use 2x N210 with 2x XCVR2450 daughter boards and I transmit
>> frames at 5785 MHz. The frames are received, but the problem is that
>> the power of the received frames varies in sinusoidal manner. The
>> scenario is static and the both stations are on 2 meters distance.
>> >>
>> >> I use 50 MSps with sc8 wire format. The modulation is BPSK and the
>> symbols are 4x oversampled and filtered with SRRC at the transmitter
>> and at the receiver. The frames burst sent is the same frame repeated.
>> >>
>> >> In power.jpg the instant power averaged over a short interval is
>> shown. The sine modulation can be easily seen.
>> >> The frames.jpg shows the instant power of the frames not averaged.
>> >> The frame.jpg shows the instant power of one frame not averaged.
>> >>
>> >> I noticed that from the TX side I have relatively strong (more than
>> I would expect) carrier, due to dc bias probably. This is probably not
>> the issue.
>> >>
>> >> Any idea what can it be, or have you seen something similar?
>> >>
>> >> BR,
>> >> Vladica
>> >>
>> >>
>> >> _______________________________________________
>> >> USRP-users mailing list
>> >> [email protected] <mailto:[email protected]>
>> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >
>> >
>> >
>> > _______________________________________________
>> > USRP-users mailing list
>> > [email protected] <mailto:[email protected]>
>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 3
Date: Sun, 22 May 2016 15:09:54 +0000
From: "Zhang, Wenyu" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] The transimitter gain of USRP NI-2920
Message-ID:
<am4pr01mb1796f0afe2a8c4d9c1dc5de992...@am4pr01mb1796.eurprd01.prod.exchangelabs.com>
Content-Type: text/plain; charset="iso-8859-1"
Dear all,
I am doing the QPSK transciever transmission with two USRPs NI-2920. As I
check from the datasheet, the maximum gain for the transmitter usrp is 31 dB.
When I set the transmitter gain at 27dB, it gets the minimum BER. However, when
I turn the gain to higher values below the maximum, the BER gets worse. I
wonder why this happens. Is it due to higher SNR leading to more packets
drop?Does anyone know the answer? Many thanks.
Kindest regards,
Barbara
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160522/55c8c13c/attachment-0001.html>
------------------------------
Message: 4
Date: Sun, 22 May 2016 10:19:10 -0500
From: Sergio Cruz Perez <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Jonathon,
I found that the problem was that the schmidlcox. xml file located in
{uhd_installation_path}/share/uhd/rfnoc/blocks doesn't have the correct
registers declared. I modified that file and uhd_rfnoc_schmidlcox.xml in my
local copy of uhd and gr-ettus repos. I reinstalled both on my pc and
cross-compiled for the E310. Now, I can see how the registers are correctly
added to the xbar:
The problem now is that every program that I run on the E310 using my fpga
image sends a message of segmentation fault.
root@ettus-e300:~/rfnoc# ./schmidl.py linux; GNU C++ version 4.9.2;
Boost_105700; UHD_003.010.rfnoc-308-g63b98f87
-- Loading FPGA image: /home/root/usrp_e310_rfnoc_fpga.bit... done--
Initializing core control...-- Performing register loopback test... pass--
Setting up dest map for ep 0 to be stream 1-- Performing register loopback
test... pass
[...] -- [RFNOC] ------- Block Setup ------------- Setting up dest map for ep
2 to be stream 7-- Setting up NoC-Shell Control #0 (SID: 00:02>02:30)...OK--
Port 48: Found NoC-Block with ID 5CC0000000000000.-- base_path =
"/usr/share/uhd/rfnoc"-- Reading XML file:
/usr/share/uhd/rfnoc/blocks/schmidlcox.xml-- [RFNoC Factory]
block_ctrl_base::make() -- base_path = "/usr/share/uhd/rfnoc"-- Reading XML
file: /usr/share/uhd/rfnoc/blocks/schmidlcox.xml-- [RFNoC Factory] Using
controller key 'Block' and block name 'SchmidlCox'-- block_ctrl_base()--
base_path = "/usr/share/uhd/rfnoc"-- Reading XML file:
/usr/share/uhd/rfnoc/blocks/schmidlcox.xml-- Found valid blockdef-- NOC ID:
0x5CC0000000000000 Block ID: 0/SchmidlCox_0-- [0/SchmidlCox_0] Adding port
definition at xbar/SchmidlCox_0/ports/in/0: type = 'sc16' pkt_size = '0' vlen =
'0'-- [0/SchmidlCox_0] Adding port definition at xbar/SchmidlCox_0/ports/out/0:
type = 'sc16' pkt_size = '%vlen' vlen = '$fftsize'-- added arg path:
xbar/SchmidlCo
x_0/args/0/fftsize/value-- added arg path:
xbar/SchmidlCox_0/args/0/frame_len/value-- added arg path:
xbar/SchmidlCox_0/args/0/gap_len/value-- added arg path:
xbar/SchmidlCox_0/args/0/offset/value-- added arg path:
xbar/SchmidlCox_0/args/0/max_num_symbols/value-- added arg path:
xbar/SchmidlCox_0/args/0/short_num_symbols/value-- added arg path:
xbar/SchmidlCox_0/args/0/threshold/value-- added arg path:
xbar/SchmidlCox_0/args/0/agc_ref_level/value-- [NocScript] Executing and
asserting code: SR_WRITE("FRAME_LENGTH", $frame_len)-- [NocScript] Executing
SR_WRITE() -- [0/SchmidlCox_0] sr_write(FRAME_LENGTH, 00000040) ==>
[0/SchmidlCox_0] sr_write(129, 00000040, 0)-- [NocScript] Executing and
asserting code: SR_WRITE("GAP_LENGTH", $gap_len)-- [NocScript] Executing
SR_WRITE() -- [0/SchmidlCox_0] sr_write(GAP_LENGTH, 00000010) ==>
[0/SchmidlCox_0] sr_write(130, 00000010, 0)-- [NocScript] Executing and
asserting code: SR_WRITE("OFFSET", $offset)-- [NocScript] Executing SR_WRITE()
--
[0/SchmidlCox_0] sr_write(OFFSET, 00000010) ==> [0/SchmidlCox_0]
sr_write(131, 00000010, 0)-- [NocScript] Executing and asserting code:
GE($max_num_symbols, 0) AND LE($max_num_symbols, 1000)-- [NocScript] Executing
and asserting code: SR_WRITE("NUM_SYMBOLS_MAX", $max_num_symbols)-- [NocScript]
Executing SR_WRITE() -- [0/SchmidlCox_0] sr_write(NUM_SYMBOLS_MAX, 0000000C)
==> [0/SchmidlCox_0] sr_write(132, 0000000C, 0)-- [NocScript] Executing and
asserting code: GE($short_num_symbols, 0) AND LE($short_num_symbols, 1000)--
[NocScript] Executing and asserting code: SR_WRITE("NUM_SYMBOLS_SHORT",
$short_num_symbols)-- [NocScript] Executing SR_WRITE() -- [0/SchmidlCox_0]
sr_write(NUM_SYMBOLS_SHORT, 00000008) ==> [0/SchmidlCox_0] sr_write(133,
00000008, 0)-- [NocScript] Executing and asserting code: GE($threshold, 0.0)
AND LE($threshold, 1.0)-- [NocScript] Executing and asserting code:
SR_WRITE("THRESHOLD", IROUND(MULT(16384.0, $threshold)))-- [NocScript]
Executing SR_WRITE() --
[0/SchmidlCox_0] sr_write(THRESHOLD, 00003800) ==> [0/SchmidlCox_0]
sr_write(134, 00003800, 0)-- [NocScript] Executing and asserting code:
GE($agc_ref_level, 0.0) AND LE($agc_ref_level, 1.0)-- [NocScript] Executing and
asserting code: SR_WRITE("AGC_REF_LEVEL", IROUND(MULT(32768.0,
$agc_ref_level)))-- [NocScript] Executing SR_WRITE() -- [0/SchmidlCox_0]
sr_write(AGC_REF_LEVEL, 00001000) ==> [0/SchmidlCox_0] sr_write(135,
00001000, 0)-- ========== Full list of RFNoC blocks: ============-- *
0/Radio_0-- * 0/Radio_1-- * 0/SchmidlCox_0-- [0/Radio_0]
block_ctrl_base::clear() -- node_ctrl_base::clear() -- [0/Radio_1]
block_ctrl_base::clear() -- node_ctrl_base::clear() -- [0/SchmidlCox_0]
block_ctrl_base::clear() -- node_ctrl_base::clear() -- [0/SchmidlCox_0]
block_ctrl_base::_clear() -- [0/SchmidlCox_0] sr_write(126, 00C1EA12, 0)--
[0/Radio_0] _resolve_port_def()-- [0/Radio_0] item type: sc16-- [0/Radio_0]
vector length: 0-- [0/Radio_0] packet size: 0-- [0/Radio_0] _resolve
_port_def()-- [0/Radio_0] item type: sc16-- [0/Radio_0] vector length: 0--
[0/Radio_0] packet size: 0
UHD Warning: The hardware does not support the requested RX sample rate:
Target sample rate: 10.000000 MSps Actual sample rate: 8.000000 MSpsenabling
rx dc offset removal: 1-- [0/SchmidlCox_0] _resolve_port_def()--
[0/SchmidlCox_0] item type: sc16-- [0/SchmidlCox_0] vector length: 0--
[0/SchmidlCox_0] packet size: 0-- [0/SchmidlCox_0] _resolve_port_def()--
[0/SchmidlCox_0] item type: sc16-- [0/SchmidlCox_0] vector length: 64--
[0/SchmidlCox_0] packet size: 64-- [NocScript] Executing and asserting code:
SR_WRITE("FRAME_LENGTH", $frame_len)-- [NocScript] Executing SR_WRITE() --
[0/SchmidlCox_0] sr_write(FRAME_LENGTH, 00000010) ==> [0/SchmidlCox_0]
sr_write(129, 00000010, 0)-- [NocScript] Executing and asserting code:
SR_WRITE("GAP_LENGTH", $gap_len)-- [NocScript] Executing SR_WRITE() --
[0/SchmidlCox_0] sr_write(GAP_LENGTH, 00000010) ==> [0/SchmidlCox_0]
sr_write(130, 00000010, 0)-- [NocScript] Executing and asserting code:
SR_WRITE("OFFSET", $offset)-- [No
cScript] Executing SR_WRITE() -- [0/SchmidlCox_0] sr_write(OFFSET, 00000000)
==> [0/SchmidlCox_0] sr_write(131, 00000000, 0)-- [NocScript] Executing and
asserting code: GE($max_num_symbols, 0) AND LE($max_num_symbols, 1000)--
[NocScript] Executing and asserting code: SR_WRITE("NUM_SYMBOLS_MAX",
$max_num_symbols)-- [NocScript] Executing SR_WRITE() -- [0/SchmidlCox_0]
sr_write(NUM_SYMBOLS_MAX, 0000000C) ==> [0/SchmidlCox_0] sr_write(132,
0000000C, 0)-- [NocScript] Executing and asserting code: GE($short_num_symbols,
0) AND LE($short_num_symbols, 1000)-- [NocScript] Executing and asserting code:
SR_WRITE("NUM_SYMBOLS_SHORT", $short_num_symbols)-- [NocScript] Executing
SR_WRITE() -- [0/SchmidlCox_0] sr_write(NUM_SYMBOLS_SHORT, 00000008) ==>
[0/SchmidlCox_0] sr_write(133, 00000008, 0)-- [NocScript] Executing and
asserting code: GE($threshold, 0.0) AND LE($threshold, 1.0)-- [NocScript]
Executing and asserting code: SR_WRITE("THRESHOLD", IROUND(MULT(16384.0,
$threshold)))-- [No
cScript] Executing SR_WRITE() -- [0/SchmidlCox_0] sr_write(THRESHOLD,
00003800) ==> [0/SchmidlCox_0] sr_write(134, 00003800, 0)-- [NocScript]
Executing and asserting code: GE($agc_ref_level, 0.0) AND LE($agc_ref_level,
1.0)-- [NocScript] Executing and asserting code: SR_WRITE("AGC_REF_LEVEL",
IROUND(MULT(32768.0, $agc_ref_level)))-- [NocScript] Executing SR_WRITE() --
[0/SchmidlCox_0] sr_write(AGC_REF_LEVEL, 00001000) ==> [0/SchmidlCox_0]
sr_write(135, 00001000, 0)Segmentation fault
I attached the files I modified. Any suggestion of what can I do now?
Thanks
Sergio
To: [email protected]
Date: Thu, 31 Mar 2016 18:37:34 -0600
Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
From: [email protected]
CC: [email protected]
Jonathon,
I'm compiling uhd locally on the E310. I installed this branch:
root@ettus-e300:~/uhd# git statusOn branch rfnoc-ofdmYour branch is up-to-date
with 'origin/rfnoc-ofdm'.
root@ettus-e300:~/uhd/fpga-src# git statusHEAD detached at b2d9bca
I did it using the next commands:
cmake -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_USRP1=OFF -DENABLE_USRP2=OFF
DENABLE_B100=OFF -DENABLE_E100=OFF -DENABLE_X300=ON -DENABLE_B200=OFF
-DENABLE_E300=ON ..
make and make install. No errors were detected when it finished.
Is this ok or I need to cross compile UHD? If I use just the rfnoc FIFO block,
I don't have the problem.
Sergio
From: [email protected]
Date: Thu, 31 Mar 2016 17:19:13 -0700
Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
To: [email protected]
CC: [email protected]
Hi Sergio,
Are you cross compiling UHD using the rfnoc-ofdm branch? If you use the built
in UHD on the fido test image it won't work since it isn't built from the
correct commit.
Jonathon
On Thu, Mar 31, 2016 at 4:56 PM, Sergio Cruz Perez <[email protected]>
wrote:
Hi Jonathon,
I'm already tested the schmidl_cox block using the rfnoc-branch branch and
using the commit commit b2d9bca4907d74059e7db5ed295df10c045e054e for the
fpga-src, but I still having the next error:
Traceback (most recent call last): File "./schmidl.py", line 192, in <module>
main() File "./schmidl.py", line 181, in main tb =
top_block_cls(chan_est=options.chan_est, freq=options.freq, gain=options.gain,
lo_offset=options.lo_offset, samp_rate=options.samp_rate) File "./schmidl.py",
line 93, in __init__ self.uhd_rfnoc_ofdm_schmidlcox_0.set_arg("offset", 77)
File "/usr/local/lib/python2.7/site-packages/ettus/ettus_swig.py", line 3002,
in set_arg return _ettus_swig.rfnoc_generic_sptr_set_arg(self,
*args)RuntimeError: LookupError: Path not found in tree:
/mboards/0/xbar/SchmidlCox_0/args/0/offset/value
Do you think I need to upgrade the firmware also to solve this? I'm currently
using the alpha/fido_rfnoc_test/sdimage-gnuradio-dev.direct.xz
ThanksSergio
From: [email protected]
Date: Wed, 30 Mar 2016 13:34:45 -0700
Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
To: [email protected]
CC: [email protected]
Hey Sergio,
I updated the commit fpga-src is pointing at in uhd/rfnoc-ofdm. Give it try now.
Jonathon
On Wed, Mar 30, 2016 at 12:31 PM, Sergio Cruz Perez <[email protected]>
wrote:
Hi Jonathon,
I used the rfnoc-ofdm branch to make the fpga image. Now I have the same
problem that I had when I used the rfnoc-devel branch:
ERROR: [Synth 8-448] named port connection 's_axis_phase_tlast' does not exist
for instance 'cfo_corrector' of module 'cordic_rotator'
[/home/sheko/uhd/fpga-src/usrp3/lib/rfnoc/schmidl_cox.v:163]
The commit of the fpga-src folder that I'm using is:
8fc97e5eeb3abfcccfb5b71e2d28717ec9b673a0 anduhd commit:
8cbec5e4b8ab5fd7c8f04c09c995d337bc0ba603.
I saw that the schmidl_cox.v that is contained in this branch of fpga-src is
older than the version in the rfnoc-ofdm branch.
When I installed uhd I changed to rfnoc-ofmd branch and then I updated the
fpga-src submodule. Is this correct?
Thanks
Sergio
From: [email protected]
Date: Mon, 28 Mar 2016 09:53:09 -0700
Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
To: [email protected]
CC: [email protected]
Hi Sergio,
I just pushed a branch on uhd called rfnoc-ofdm. Give that one a try.
Jonathon
On Thu, Mar 24, 2016 at 11:35 AM, Sergio Cruz Perez <[email protected]>
wrote:
Hi Jonathon,
I'm using commit b7546712aa0091f87b793ef4c4a9e9c084467173
Thanks
Sergio
From: [email protected]
Date: Wed, 23 Mar 2016 20:12:59 -0700
Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
To: [email protected]
CC: [email protected]
Hi Sergio,
Looks like the block is being enumerated but UHD is not populating the property
tree correctly. What commit of UHD rfnoc-devel are you using?
Jonathon
On Wed, Mar 23, 2016 at 11:15 AM, Sergio Cruz Perez <[email protected]>
wrote:
Hi Jonathon,
Finally I could make the image updating the e300_core.v file as you said. I ran
the uhd_usrp_probe init only and now I can see the rfnoc blocks schmidl_cox and
fifo.
-- ========== Full list of RFNoC blocks: ============-- * 0/Radio_0-- *
0/Radio_1-- * 0/FIFO_0-- * 0/SchmidlCox_0
But, when i run my application I got again the same problem:
...
-- [0/SchmidlCox_0] _resolve_port_def()-- [0/SchmidlCox_0] item type: sc16--
[0/SchmidlCox_0] vector length: 0-- [0/SchmidlCox_0] packet size: 0--
[0/SchmidlCox_0] _resolve_port_def()-- [0/SchmidlCox_0] item type: sc16--
[0/SchmidlCox_0] vector length: 64-- [0/SchmidlCox_0] packet size: 64--
[NocScript] Executing and asserting code: SR_WRITE("CP_LENGTH", $cp_len)--
[NocScript] Executing SR_WRITE() -- [0/SchmidlCox_0] sr_write(CP_LENGTH,
00000040) ==> [0/SchmidlCox_0] sr_write(130, 00000040, 0)-- [NocScript]
Executing and asserting code: GE($threshold, 0.0) AND LE($threshold, 1.0)--
[NocScript] Executing and asserting code: SR_WRITE("THRESHOLD",
IROUND(MULT(32768.0, $threshold)))-- [NocScript] Executing SR_WRITE() --
[0/SchmidlCox_0] sr_write(THRESHOLD, 00007000) ==> [0/SchmidlCox_0]
sr_write(134, 00007000, 0)Traceback (most recent call last): File
"./rx_rfnoc.py", line 207, in <module> main() File "./rx_rfnoc.py", line
196, in main tb = top_block_cls(chan_
est=options.chan_est, freq=options.freq, gain=options.gain,
lo_offset=options.lo_offset, samp_rate=options.samp_rate) File
"./rx_rfnoc.py", line 97, in __init__
self.uhd_rfnoc_ofdm_schmidlcox_0.set_arg("offset", 77) File
"/usr/local/lib/python2.7/site-packages/ettus/ettus_swig.py", line 3002, in
set_arg return _ettus_swig.rfnoc_generic_sptr_set_arg(self,
*args)RuntimeError: LookupError: Path not found in tree:
/mboards/0/xbar/SchmidlCox_0/args/0/offset/value...
How is that path generated? I can't find it on the E310
From: [email protected]
Date: Tue, 22 Mar 2016 15:17:40 -0700
Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
To: [email protected]
CC: [email protected]
Sergio,
rfnoc-ofdm has gotten a little out of sync with UHD rfnoc-devel. The compat
number on line 172 in e300_core.v needs to be updated to RB32_CORE_COMPAT :
rb_data <= {8'hAC, 8'h0, 8'h255, 8'h0};
I am going to merge rfnoc-ofdm into rfnoc-radio-redo soon which will fix this
issue. This temporary fix should hold you over until the merge.
Jonathon
On Tue, Mar 22, 2016 at 3:07 PM, Sergio Cruz Perez <[email protected]>
wrote:
Hi Jonathon,
It's a GNU radio flowgraph and I'm using my rfnoc fpga image. I copied the
image that I made on my PC using the rfnoc-ofdm branches to the E310. My
flowgraph has the root to that image in the device3 args so when I run my
applications I can see that it's loading my image.
root@ettus-e300:~/pruebas# ./rx_rfnoc.py linux; GNU C++ version 4.9.2;
Boost_105700; UHD_003.010.rfnoc-316-gb7546712
-- Loading FPGA image: /home/root/sheko/usrp_e310_rfnoc_fpga.bit... done--
Initializing core control...-- Performing register loopback test... pass .....
When I don't use the rfnoc-ofdm branches I can make the image and run it on the
E310 but I return to the first problem of this thread.
Thanks
Sergio
From: [email protected]
Date: Tue, 22 Mar 2016 14:23:28 -0700
Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
To: [email protected]
CC: [email protected]
Hi Sergio,
You need copy your bitstream to the E310 and replace
/usr/share/uhd/images/usrp_e300_fpga.bit. How are you running your application?
Is it a GNU Radio flowgraph?
Jonathon
On Tue, Mar 22, 2016 at 10:56 AM, Sergio Cruz Perez <[email protected]>
wrote:
Hi Jonathon,
I installed uhd rfnoc-devel version with the rfnoc-ofdm branches on both the
PC and the E310 (UHD_003.010.rfnoc-316-gb7546712). I made the image with the
schmidl_cox block but when I run my application, I got the next error:
RuntimeError: Expected FPGA compatibility number 255.x, but got 7.0:The FPGA
build is not compatible with the host code build.
What should I update on my PC to make a compatible image with the E310?
RegardsSergio
From: [email protected]
Date: Wed, 9 Mar 2016 13:05:58 -0800
Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
To: [email protected]
CC: [email protected]
Hi Sergio,
Try using the "rfnoc-ofdm" branches for uhd and gr-ettus and rebuild your FPGA
image. Make sure to add the schmidl_cox block to rfnoc_e310_ce_auto_inst.v and
run 'make cleanall' before building the FPGA image.
Jonathon
On Tue, Mar 8, 2016 at 8:31 PM, Sergio Cruz Perez <[email protected]> wrote:
Hi Jonathon,
Yes, I followed the RFNoC:Getting started guide to install the rfnoc-devel
branch and the gr-ettus OOT module. I forgot to mention that in my first
attempt to make the fpga image I had the next error:
ERROR: [Synth 8-448] named port connection 's_axis_phase_tlast' does not exist
for instance 'cfo_corrector' of module 'cordic_rotator'
[/home/sheko/uhd/fpga-src/usrp3/lib/rfnoc/schmidl_cox.v:163]
I removed that port in the schmidl_cox.v file and then it was possible to make
the image with the schmidl_cox block.
Thanks
Sergio
From: [email protected]
Date: Tue, 8 Mar 2016 16:51:20 -0800
Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
To: [email protected]
CC: [email protected]
Hi Sergio,
Are you using the rfnoc-ofdm branches for uhd and gr-ettus?
Jonathon
On Tue, Mar 8, 2016 at 4:31 PM, Sergio Cruz Perez via USRP-users
<[email protected]> wrote:
Hi,
I'm learning to use RFNoC to implement an OFDM receiver on a E310. The
original FPGA image had just 3 RFNoC blocks: FIFO, Window and FFT, so I made a
new image removing the window and the FFT blocks and replacing them for a
schmidl_cox block. When I run my application with the new image I get the next
error:
File "/usr/local/lib/python2.7/site-packages/ettus/ettus_swig.py", line 3002,
in set_argreturn _ettus_swig.rfnoc_generic_sptr_set_arg(self, *args)
RuntimeError: LookupError: Path not found in tree:
/mboards/0/xbar/SchmidlCox_0/args/0/offset/value
Has anyone run into the same problem?
I'm using UHD_003.010.rfnoc-314-gf773e72b
Thanks
Sergio Cruz
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160522/6b27df50/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: schmidlcox.xml
Type: application/xml
Size: 3082 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160522/6b27df50/attachment-0002.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uhd_rfnoc_schmidlcox.xml
Type: application/xml
Size: 3799 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160522/6b27df50/attachment-0003.xml>
------------------------------
Message: 5
Date: Sun, 22 May 2016 09:23:42 -0600
From: Steven Knudsen <[email protected]>
To: "Zhang, Wenyu" <[email protected]>
Cc: USRP-users <[email protected]>
Subject: Re: [USRP-users] The transimitter gain of USRP NI-2920
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
I am not familiar with the NI-2920 per se, but experience says that once you
start pushing gain stages to their max, linearity starts to suffer. Take a look
at the datasheets for the output stage and see what the gain and phase looks
like at the top end.
Others on the list will undoubtedly have better insight, I?m just going from
experience?
have fun!
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen
All the wires are cut, my friends
Live beyond the severed ends. Louis MacNeice
> On May 22, 2016, at 09:09, Zhang, Wenyu via USRP-users
> <[email protected]> wrote:
>
> Dear all,
> I am doing the QPSK transciever transmission with two USRPs NI-2920. As I
> check from the datasheet, the maximum gain for the transmitter usrp is 31 dB.
> When I set the transmitter gain at 27dB, it gets the minimum BER. However,
> when I turn the gain to higher values below the maximum, the BER gets worse.
> I wonder why this happens. Is it due to higher SNR leading to more packets
> drop?Does anyone know the answer? Many thanks.
> Kindest regards,
> Barbara
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160522/fab42073/attachment-0001.html>
------------------------------
Message: 6
Date: Sun, 22 May 2016 17:32:42 +0200
From: Elvis Angelaccio <[email protected]>
To: [email protected]
Subject: [USRP-users] uhd.tune_request always returns 0
Message-ID:
<caln1cnt3hgwemahxklobhjfsdtmwuo-fs8b068nxietjsc4...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi, can someone explain me why `uhd.tune_request` always returns 0 in
the following Python code?
I'm running this on Linux with a USRP1 attached via USB.
The USRP has two 900 MHz daughterboards and two antennas attached to
TX/RX ports.
Gnuradio version = 3.7.9.2
UHD version = 3.9.3
### CODE Snippet ####
d = uhd.find_devices(uhd.device_addr(args.address_args))
if d:
print 'Available UHD devices: ' + str(d)
try:
uhd_type = d[0].get('type')
except IndexError:
print 'Fatal error. Did you connect the USRP to an USB port?'
sys.exit(1)
serial = d[0].get('serial')
tx = uhd.usrp_sink(
device_addr='serial=' + serial,
stream_args=uhd.stream_args(
'fc32',
channels=range(1)
)
)
tx_center_freq = uhd.tune_request(freq)
if not tx_center_freq: # <===== Always happening.
print 'Could not set TX freq'
sys.exit(1)
tx.set_center_freq(tx_center_freq)
...
Best regards,
Elvis
------------------------------
Message: 7
Date: Sun, 22 May 2016 17:46:02 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] uhd.tune_request always returns 0
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hm, interesting. I shouldn't have thought so, but: /something's/
strange, and for some reason, perfectly valid uhd.tune_request objects
evaluate to False in this case.
So: since there's hardly any case that you can mis-construct a tune
request (any frequency that is numerical should be fine, even negative
numbers), I'd say: drop your "if not tx_center_freq" clause and just
check whether the properties of the uhd.tune_result that
tx.set_center_freq() return match your expectation.
Best regards,
Marcus
On 22.05.2016 17:32, Elvis Angelaccio via USRP-users wrote:
> Hi, can someone explain me why `uhd.tune_request` always returns 0 in
> the following Python code?
> I'm running this on Linux with a USRP1 attached via USB.
> The USRP has two 900 MHz daughterboards and two antennas attached to
> TX/RX ports.
>
> Gnuradio version = 3.7.9.2
> UHD version = 3.9.3
>
> ### CODE Snippet ####
>
> d = uhd.find_devices(uhd.device_addr(args.address_args))
> if d:
> print 'Available UHD devices: ' + str(d)
>
> try:
> uhd_type = d[0].get('type')
> except IndexError:
> print 'Fatal error. Did you connect the USRP to an USB port?'
> sys.exit(1)
>
> serial = d[0].get('serial')
> tx = uhd.usrp_sink(
> device_addr='serial=' + serial,
> stream_args=uhd.stream_args(
> 'fc32',
> channels=range(1)
> )
> )
>
> tx_center_freq = uhd.tune_request(freq)
>
> if not tx_center_freq: # <===== Always happening.
> print 'Could not set TX freq'
> sys.exit(1)
>
> tx.set_center_freq(tx_center_freq)
> ...
>
>
> Best regards,
> Elvis
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160522/3ee7a0b8/attachment-0001.html>
------------------------------
Message: 8
Date: Sun, 22 May 2016 11:51:30 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] uhd.tune_request always returns 0
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 05/22/2016 11:46 AM, Marcus M?ller via USRP-users wrote:
> Hm, interesting. I shouldn't have thought so, but: /something's/
> strange, and for some reason, perfectly valid uhd.tune_request objects
> evaluate to False in this case.
>
> So: since there's hardly any case that you can mis-construct a tune
> request (any frequency that is numerical should be fine, even negative
> numbers), I'd say: drop your "if not tx_center_freq" clause and just
> check whether the properties of the uhd.tune_result that
> tx.set_center_freq() return match your expectation.
>
> Best regards,
> Marcus
What are the boolean semantics of a structured data type like a
tune_request_t ? It's not immediately clear to me that there is a mapping
in boolean for such structured data types.
>
> On 22.05.2016 17:32, Elvis Angelaccio via USRP-users wrote:
>> Hi, can someone explain me why `uhd.tune_request` always returns 0 in
>> the following Python code?
>> I'm running this on Linux with a USRP1 attached via USB.
>> The USRP has two 900 MHz daughterboards and two antennas attached to
>> TX/RX ports.
>>
>> Gnuradio version = 3.7.9.2
>> UHD version = 3.9.3
>>
>> ### CODE Snippet ####
>>
>> d = uhd.find_devices(uhd.device_addr(args.address_args))
>> if d:
>> print 'Available UHD devices: ' + str(d)
>>
>> try:
>> uhd_type = d[0].get('type')
>> except IndexError:
>> print 'Fatal error. Did you connect the USRP to an USB port?'
>> sys.exit(1)
>>
>> serial = d[0].get('serial')
>> tx = uhd.usrp_sink(
>> device_addr='serial=' + serial,
>> stream_args=uhd.stream_args(
>> 'fc32',
>> channels=range(1)
>> )
>> )
>>
>> tx_center_freq = uhd.tune_request(freq)
>>
>> if not tx_center_freq: # <===== Always happening.
>> print 'Could not set TX freq'
>> sys.exit(1)
>>
>> tx.set_center_freq(tx_center_freq)
>> ...
>>
>>
>> Best regards,
>> Elvis
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160522/063bfbf6/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 69, Issue 22
******************************************
