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. Scaling X300 Rx values to dBm (Vladimir)
2. Re: Scaling X300 Rx values to dBm (Dan CaJacob)
3. Re: Scaling X300 Rx values to dBm (Marcus M?ller)
4. Re: Scaling X300 Rx values to dBm (Vladimir)
5. USRP B210 Floating Wire Connections in the RTL Schematic
(altu? kaya)
6. make rfnoc module for USRP E312 (??)
7. Re: make rfnoc module for USRP E312 (Neel Pandeya)
8. Re: E310 gnuradio not showing RFNoC blocks (Jason Matusiak)
9. Re: E310 gnuradio not showing RFNoC blocks (Jason Matusiak)
10. Re: Does send block the thread? (Jacob Knoles)
----------------------------------------------------------------------
Message: 1
Date: Sun, 25 Jun 2017 23:09:15 +0300
From: Vladimir <[email protected]>
To: [email protected]
Subject: [USRP-users] Scaling X300 Rx values to dBm
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hello,
Can anybody help me instructing how to obtain dBm values for usrp input stream?
From what I have seen in online docs, I understood that now float values that
uhd returns from the device are just?sc16 ADC values scaled to some given
range, is it right? That means they are proportional to amplitude values of the
input signal, is it right? What would be the formula to rescale values for a
given HF value? I understand that to measure power with some accuracy,
theoretically I should make kind of calibration procedure for every HF in the
range, but now we don't have to measure it accurate, just to have the
estimation with moderate accuracy of what kind of signal level do we have,
comparable to what regular spectrum analyzer shows. Or, is it already
implemented in uhd and I just didn't find it?
Thank you!
Vladimir
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170625/2f9c45a8/attachment-0001.html>
------------------------------
Message: 2
Date: Sun, 25 Jun 2017 21:16:25 +0000
From: Dan CaJacob <[email protected]>
To: Vladimir <[email protected]>, [email protected]
Subject: Re: [USRP-users] Scaling X300 Rx values to dBm
Message-ID:
<camomjocqsinu1khkymdekrwpphjrcg5vgnzpgpoagd726fz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
You'd have to calibrate the instrument using a known signal generator.
On Sun, Jun 25, 2017 at 4:10 PM Vladimir via USRP-users <
[email protected]> wrote:
> Hello,
>
> Can anybody help me instructing how to obtain dBm values for usrp input
> stream? From what I have seen in online docs, I understood that now float
> values that uhd returns from the device are just sc16 ADC values scaled to
> some given range, is it right? That means they are proportional to
> amplitude values of the input signal, is it right? What would be the
> formula to rescale values for a given HF value? I understand that to
> measure power with some accuracy, theoretically I should make kind of
> calibration procedure for every HF in the range, but now we don't have to
> measure it accurate, just to have the estimation with moderate accuracy of
> what kind of signal level do we have, comparable to what regular spectrum
> analyzer shows. Or, is it already implemented in uhd and I just didn't find
> it?
>
> Thank you!
> Vladimir
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
--
Very Respectfully,
Dan CaJacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170625/0e68da28/attachment-0001.html>
------------------------------
Message: 3
Date: Sun, 25 Jun 2017 23:18:01 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Scaling X300 Rx values to dBm
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Vladimir,
the USRPs are not calibrated measurement equipment. The digital values
you see for real and imaginary part (in [-1,1]) of the complex numbers
you're getting from the USRP are *proportional* to the voltage seen by
the ADC, but that is also only proportional to the voltage seen at the
RX SMA connector. And these proportionality factors will depend on
frequency, gain, temperature, sample rate, ?
So, it's really just a factor. But: that factor depends on very, very,
very many properties, and you'll need to calibrate with a known power
source, not only theoretically, but very practically!
So, get a source of known power, somehow get that power into the system
you want to calibrate (that often includes antennas, not only the
USRP!!), and then calibrate, at *exactly* the frequency, gain, sample
rate settings that you want to use. Make sure you're not driving the RX
chain into saturation!
Best regards,
Marcus
On 25.06.2017 22:09, Vladimir via USRP-users wrote:
> Hello,
>
> Can anybody help me instructing how to obtain dBm values for usrp
> input stream? From what I have seen in online docs, I understood that
> now float values that uhd returns from the device are just sc16 ADC
> values scaled to some given range, is it right? That means they are
> proportional to amplitude values of the input signal, is it right?
> What would be the formula to rescale values for a given HF value? I
> understand that to measure power with some accuracy, theoretically I
> should make kind of calibration procedure for every HF in the range,
> but now we don't have to measure it accurate, just to have the
> estimation with moderate accuracy of what kind of signal level do we
> have, comparable to what regular spectrum analyzer shows. Or, is it
> already implemented in uhd and I just didn't find it?
>
> Thank you!
> Vladimir
>
>
>
>
>
> _______________________________________________
> 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/20170625/d3bf1f09/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 26 Jun 2017 13:52:06 +0300
From: Vladimir <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Scaling X300 Rx values to dBm
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Marcus,
Thank you for the clarification!
Vladimir
>???????????, 26 ???? 2017, 0:19 +03:00 ?? Marcus M?ller via USRP-users
><[email protected]>:
>
>Hi Vladimir,
>the USRPs are not calibrated measurement equipment. The digital
values you see for real and imaginary part (in [-1,1]) of the
complex numbers you're getting from the USRP are *proportional* to
the voltage seen by the ADC, but that is also only proportional to
the voltage seen at the RX SMA connector. And these
proportionality factors will depend on frequency, gain,
temperature, sample rate, ?
>So, it's really just a factor. But: that factor depends on very,
very, very many properties, and you'll need to calibrate with a
known power source, not only theoretically, but very practically!
>So, get a source of known power, somehow get that power into the
system you want to calibrate (that often includes antennas, not
only the USRP!!), and then calibrate, at *exactly* the frequency,
gain, sample rate settings that you want to use. Make sure you're
not driving the RX chain into saturation!
>Best regards,
>Marcus
>On 25.06.2017 22:09, Vladimir via
USRP-users wrote:
>>Hello,
>>
>>Can anybody help me instructing how to obtain dBm values for usrp
input stream? From what I have seen in online docs, I understood
that now float values that uhd returns from the device are
just?sc16 ADC values scaled to some given range, is it right? That
means they are proportional to amplitude values of the input
signal, is it right? What would be the formula to rescale values
for a given HF value? I understand that to measure power with some
accuracy, theoretically I should make kind of calibration
procedure for every HF in the range, but now we don't have to
measure it accurate, just to have the estimation with moderate
accuracy of what kind of signal level do we have, comparable to
what regular spectrum analyzer shows. Or, is it already
implemented in uhd and I just didn't find it?
>>
>>Thank you!
>>Vladimir
>>
>>
>>>
>>
>>
>>_______________________________________________
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/20170626/7086e6a0/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 26 Jun 2017 11:57:55 +0200
From: altu? kaya <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP B210 Floating Wire Connections in the RTL
Schematic
Message-ID:
<CAHq6UV8WigkXMzv2E1K=jqaxgeqg8hp55drklpr1nksh2iu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello everyone,
I synthesized and mapped the B210 FPGA code provided in
https://github.com/EttusResearch/fpga. However, there are some unwired,
floating wires in the RTL schematic, I attached a screen shot of it.
Another abnormality in the RTL schematic is in b200_core module. Only two
of the input wires are not connected and those are rx0 and rx1 (Screen shot
is attached). Are not those are the main output of the ADC? If not, where
is the main output of the ADC?
Looking forward your answers,
Altug Kaya
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170626/e5bdcfba/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: b200_io floating wires.PNG
Type: image/png
Size: 32216 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170626/e5bdcfba/attachment-0002.PNG>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: b200_core unconnected rx0 and rx1.PNG
Type: image/png
Size: 24513 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170626/e5bdcfba/attachment-0003.PNG>
------------------------------
Message: 6
Date: Mon, 26 Jun 2017 15:20:14 +0800 (CST)
From: ?? <[email protected]>
To: USRP_FPGA <[email protected]>
Subject: [USRP-users] make rfnoc module for USRP E312
Message-ID: <[email protected]>
Content-Type: text/plain; charset="gbk"
I don't know what parameter should be filled for DUHD_FPGA_DIR.
When I run cmake ../, the system report "/bin/sh: 1: source: not found"
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170626/67c0d8c5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: question.png
Type: image/png
Size: 6390 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170626/67c0d8c5/attachment-0001.png>
------------------------------
Message: 7
Date: Mon, 26 Jun 2017 06:55:45 -0700
From: Neel Pandeya <[email protected]>
To: ?? <[email protected]>
Cc: USRP_FPGA <[email protected]>
Subject: Re: [USRP-users] make rfnoc module for USRP E312
Message-ID:
<cacaxmv_huetpo8y_trwlh55gdtvihbnlmfanwet+9uynewx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Are you using PyBOMBS?
What is the path on your system to the E312 FPGA source code repository?
Are you using Bash as your default shell? You can set this with the command
below. Select "No" when prompted.
sudo dpkg-reconfigure dash
--?Neel Pandeya
On 26 June 2017 at 00:20, ?? via USRP-users <[email protected]>
wrote:
> I don't know what parameter should be filled for DUHD_FPGA_DIR.
> When I run cmake ../, the system report "/bin/sh: 1: source: not found"
>
>
>
>
>
>
>
>
>
> _______________________________________________
> 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/20170626/56e1be6a/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 26 Jun 2017 10:23:56 -0400
From: Jason Matusiak <[email protected]>
To: [email protected], Martin Braun <[email protected]>
Subject: Re: [USRP-users] E310 gnuradio not showing RFNoC blocks
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Ah, good thinking. I rebuilt it in cross-complile mode and installed
it, now I see the blocks. I couldn't get it to run a flowgraph, so I
decided to cross-compile GR and reinstall that and did. I can open GRC
and drop blocks in, but when I go to run my VERY simple flowgraph, GRC
(I am running it with the ssh -X command) reports: "Done (return code -11)"
Any idea what I am missing there?
Thanks
~J
On 06/23/2017 06:02 PM, Martin Braun via USRP-users wrote:
> On Fri, Jun 23, 2017 at 11:13:27AM -0400, Jason Matusiak via USRP-users wrote:
>> My fresh E310 seems to be running fine and a uhd_usrp_probe shows me the
>> default RFNoC blocks, so I know the bitfile and UHD is good.
>>
>> When I run GRC on there are no RFNoC blocks or the device3 block, is there a
>> step I missed (I don't usually have all these issues with my host machine
>> and my X310)?
> The blocks in GRC are not related to the device you're running -- is
> gr-ettus properly installed?
>
> -- M
>
>
> _______________________________________________
> 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/20170626/ad37c6bb/attachment-0001.html>
------------------------------
Message: 9
Date: Mon, 26 Jun 2017 10:53:06 -0400
From: Jason Matusiak <[email protected]>
To: [email protected], Martin Braun <[email protected]>
Subject: Re: [USRP-users] E310 gnuradio not showing RFNoC blocks
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
A little more info. I ran it through GDB (of which I am not
proficient), and it errored out with this:
Program received signal SIGILL, Illegal instruction.
_armv7_tick () at armv4cpuid.S:94
94 mrrc p15,1,r0,r1,c14 @ CNTVCT
On 06/26/2017 10:23 AM, Jason Matusiak wrote:
> Ah, good thinking. I rebuilt it in cross-complile mode and installed
> it, now I see the blocks. I couldn't get it to run a flowgraph, so I
> decided to cross-compile GR and reinstall that and did. I can open
> GRC and drop blocks in, but when I go to run my VERY simple flowgraph,
> GRC (I am running it with the ssh -X command) reports: "Done (return
> code -11)"
>
> Any idea what I am missing there?
>
> Thanks
> ~J
>
> On 06/23/2017 06:02 PM, Martin Braun via USRP-users wrote:
>> On Fri, Jun 23, 2017 at 11:13:27AM -0400, Jason Matusiak via USRP-users
>> wrote:
>>> My fresh E310 seems to be running fine and a uhd_usrp_probe shows me the
>>> default RFNoC blocks, so I know the bitfile and UHD is good.
>>>
>>> When I run GRC on there are no RFNoC blocks or the device3 block, is there a
>>> step I missed (I don't usually have all these issues with my host machine
>>> and my X310)?
>> The blocks in GRC are not related to the device you're running -- is
>> gr-ettus properly installed?
>>
>> -- M
>>
>>
>> _______________________________________________
>> 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/20170626/ed226bf3/attachment-0001.html>
------------------------------
Message: 10
Date: Mon, 26 Jun 2017 08:09:56 -0700
From: Jacob Knoles <[email protected]>
To: Martin Braun <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Does send block the thread?
Message-ID:
<CA+z4yFFJqMVCi7r=tvg-xffkuuz0ovizhekum_oyycoeefe...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Martin,
OK I see. Thank you. I was able to get the functionality I need working.
All the explanations have been incredibly helpful. Thanks.
-- Jacob
On Sat, Jun 24, 2017 at 9:39 AM, Martin Braun via USRP-users <
[email protected]> wrote:
> On Fri, Jun 23, 2017 at 03:25:40PM -0700, Jacob Knoles wrote:
> > Hey Martin,?
> > I am not sure I fully understand. I get that when the samples leave
> the
> > buffer there will be a delay before they hit the antenna. But it
> seems to
> > me that you are suggesting that send() will not return until the
> samples
> > leave the buffer? This does not appear to be the case for me, as I am
> > doing what you have described, the burst trigger time is well in the
> > future but according to my diagnostic output send() returns almost
> > instantly. By time stamping the diagnostic output I can clearly see
> when
> > the buffer fills and send blocks the thread but it is not until many
> many
> > many samples are sent.?
>
> Jacob,
>
> I'm talking about your buffer (the one you pass into send). It takes
> some take to read data out of the buffer, convert it to what the device
> expects, packetize and put on the transport. send() could in theory even
> return before the samples leave the computer UHD is running on, but it
> won't return until it's safe to re-use that buffer.
>
> -- M
>
> > -----------------------------
> > Jacob Knoles
> > Compliance Engineer / Software Developer
> > MiCOM Labs Inc.
> > Pleasanton, CA
> > On Fri, Jun 23, 2017 at 3:00 PM, Martin Braun via USRP-users
> > <[email protected]> wrote:
> >
> > On Fri, Jun 23, 2017 at 11:46:05AM -0700, Jacob Knoles via
> USRP-users
> > wrote:
> > >? ? Thank you Dave that makes a lot of sense and seems to be the
> case
> > here. I
> > >? ? am getting much better results by forcing my function thread
> to
> > wait after
> > >? ? issuing all of the transmit commands for all of my bursts
> and in
> > my output
> > >? ? I can clearly see where the usrp buffer is filling up and
> causing
> > the
> > >? ? thread to block!
> > >? ? Thanks again!!
> >
> > For the record, send() will block until all the samples are released
> > from the buffer, and on the way to the antenna. That doesn't mean
> > they're sent. You could have a send time set that's way in the
> future,
> > and as long as the device can buffer, it'll accept samples.
> >
> > However, it'll block until samples were read from the user buffer.
> That
> > means when send() returns, you can overwrite the parts of the input
> > buffer that were read (and you use the return value of send() to
> figure
> > out how many samples were read exactly).
> >
> > -- M
> >
> > >
> > >? ? On Fri, Jun 23, 2017 at 11:03 AM, Dave NotTelling
> > <[email protected]>
> > >? ? wrote:
> > >
> > >? ? ? I think that the send() command will block until the data
> is
> > transmitted
> > >? ? ? *or* until all of the data can be copied over to RAM on
> the
> > radio.?*?
> > >? ? ? Check
> > >? ? ?
> > out?*? http://lists.ettus.com/pipermail/usrp-users_lists.
> ettus.com/2016-November/022482.html.
> > >? ? ? On Fri, Jun 23, 2017 at 1:17 PM, Jacob Knoles via
> USRP-users
> > >? ? ? <[email protected]> wrote:
> > >
> > >? ? ? ? The UHD API and several examples indicate that
> > tx_stream->send(...)
> > >? ? ? ? will block the thread until the samples have been
> sent, and
> > if the
> > >? ? ? ? metadata provided has a time_spec then it will block
> until
> > that time
> > >? ? ? ? has come. I am not seeing this behavior at all, in
> fact if
> > I do not
> > >? ? ? ? manually block the thread it will fly through all the
> send
> > commands
> > >? ? ? ? and bursts I need to send, end the function, thus
> closing
> > the stream,
> > >? ? ? ? and I get no output at all...?
> > >? ? ? ? What is going on here??*?
> > >? ? ? ? How can I send multiple bursts that are time specific?
> > >? ? ? ? Please help.
> > >? ? ? ? -----------------------------
> > >? ? ? ? Jacob Knoles
> >
> > _______________________________________________
> > 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/20170626/484a1d49/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 82, Issue 25
******************************************
