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: GRC -- cannot move Flow Graph blocks (Nicholas Corgan)
2. Questions about benchmark_tx/benchmark_rx (Weixian Zhou)
3. WBX Frequency Response (Simon HB9DRV)
4. Re: Questions about benchmark_tx/benchmark_rx (Shen Wenbo)
5. Re: WBX Frequency Response (Josh Blum)
6. Re: WBX Frequency Response (Simon HB9DRV)
7. Re: [Discuss-gnuradio] dc offset is different from unit to
unit (John Malsbury)
----------------------------------------------------------------------
Message: 1
Date: Fri, 01 Jun 2012 09:14:46 -0700
From: Nicholas Corgan <[email protected]>
To: Stan Gamla <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] GRC -- cannot move Flow Graph blocks
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
What OS are you using?
There is a known issue of the drag-and-drop functionality of GRC not
working in Windows due to an issue with PyGTK.
On 06/01/2012 12:56 AM, Stan Gamla wrote:
> This sounds very dumb.
> In GNU Radio Companion I can both open existing examples and can
> create my own flow graphs by placing blocks from the library panel in
> to the design space. However, I cannot move the blocks even though I
> can edit their properties. Shouldn't it be just a case of click and
> drag? What could be missing, something from Python?
> TIA
> Stan
>
>
> _______________________________________________
> 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/20120601/c72b7898/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 1 Jun 2012 13:01:36 -0400
From: Weixian Zhou <[email protected]>
To: [email protected], usrp-users <[email protected]>
Subject: [USRP-users] Questions about benchmark_tx/benchmark_rx
Message-ID:
<caherwctb7tve7z5hcg6hpag7jpq6kqbu+flkn7oqtxft-w0...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I used the benchmark_tx and benchmark_rx to transmit data and I have some
questions:
1. I set the frequency of both benchmark_tx and benchmark_rx to 300M, the
transmission succeed; but it failed when I set the frequency to 2.4G or
other frequencies. Why is this?
2. Both the benchmark_tx and benchmark_rx gives the warning as I marked
red: the actual frequency is not same but the transmission succeed. Why is
it?
3. In the receiving end, the pktno is disordered some pktnos are much
larger than averages. Why is it?
4. What does the n_right=0 means? Does it mean the packet is corrupted in
the receiving end?
*The benchmark_tx messages as following:*
belltestbed@belltestbed-OptiPlex-790
:~/Desktop/gnuradio/gr-digital/les/narrowband$ ./benchmark_tx.py -f 300M
--from-file=pic.jpg
linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.002-128-g12f7a5c9
>>> gr_fir_ccf: using SSE
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
UHD Warning:
The recv buffer could not be resized sufficiently.
Target sock buff size: 50000000 bytes.
Actual sock buff size: 1000000 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=50000000
UHD Warning:
The recv buffer could not be resized sufficiently.
Target sock buff size: 50000000 bytes.
Actual sock buff size: 1000000 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=50000000
UHD Warning:
The send buffer could not be resized sufficiently.
Target sock buff size: 1048576 bytes.
Actual sock buff size: 1000000 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.wmem_max=1048576
UHD Warning:
Unable to set the thread priority. Performance may be negatively
affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam
No gain specified.
Setting gain to 17.500000 (from [0.000000, 35.000000])
UHD Warning:
The hardware does not support the requested TX frequency:
Target frequency: 300.000000 MHz
Actual frequency: 4500.000000 MHz
UHD Warning:
The hardware does not support the requested TX sample rate:
Target sample rate: 0.050000 MSps
Actual sample rate: 0.195312 MSps
Symbol Rate: 25000.000000
Requested sps: 2.000000
Given sample rate: 195312.500000
Actual sps for rate: 7.812500
Requested sample rate: 50000.000000
Actual sample rate: 195312.500000
Using Volk machine: avx_32
Warning: failed to enable realtime scheduling
.........................................................................
*And the benchmark_rx messages as follwing:*
bell@bell-HP-Compaq-4000-Pro-SFF-PC
:~/Desktop/USRP/gnuradio/gr-digital/examples/narrowband$ ./benchmark_rx.py
-f 300M
linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.001-129-g23344268
>>> gr_fir_ccf: using SSE
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
UHD Warning:
The recv buffer could not be resized sufficiently.
Target sock buff size: 50000000 bytes.
Actual sock buff size: 1000000 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=50000000
UHD Warning:
The recv buffer could not be resized sufficiently.
Target sock buff size: 50000000 bytes.
Actual sock buff size: 1000000 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=50000000
UHD Warning:
The send buffer could not be resized sufficiently.
Target sock buff size: 1048576 bytes.
Actual sock buff size: 1000000 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.wmem_max=1048576
UHD Warning:
Unable to set the thread priority. Performance may be negatively
affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam
No gain specified.
Setting gain to 49.500000 (from [0.000000, 99.000000])
UHD Warning:
The hardware does not support the requested RX frequency:
Target frequency: 300.000000 MHz
Actual frequency: 2400.000000 MHz
UHD Warning:
The hardware does not support the requested RX sample rate:
Target sample rate: 0.050000 MSps
Actual sample rate: 0.195312 MSps
Symbol Rate: 25000.000000
Requested sps: 2.000000
Given sample rate: 195312.500000
Actual sps for rate: 7.812500
Requested sample rate: 50000.000000
Actual sample rate: 195312.500000
Warning: Failed to enable realtime scheduling.
Using Volk machine: ssse3_32
ok = False pktno = 3850 n_rcvd = 1 n_right = 0
ok = False pktno = 53042 n_rcvd = 2 n_right = 0
ok = False pktno = 61454 n_rcvd = 3 n_right = 0
ok = False pktno = 27 n_rcvd = 4 n_right = 0
ok = False pktno = 41 n_rcvd = 5 n_right = 0
ok = False pktno = 44 n_rcvd = 6 n_right = 0
ok = False pktno = 44 n_rcvd = 7 n_right = 0
ok = False pktno = 51 n_rcvd = 8 n_right = 0
ok = False pktno = 43 n_rcvd = 9 n_right = 0
ok = False pktno = 64 n_rcvd = 10 n_right = 0
I am using two USRP N210.
--
Regards,
Weixian Zhou
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120601/bf09a179/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 1 Jun 2012 21:35:13 +0200
From: "Simon HB9DRV" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] WBX Frequency Response
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi All,
After much keyboard pounding I've managed to get data from my WBX (Windows
7, 64-bit, Debug mode). Please look at the screenshot below, the sample rate
( using set_rx_rate() ) is 4MB. The response doesn't seem flat when the
sample rate is anything above 2MB. Is this to be expected? I have set the RF
Gain to the maximum of 38dB.
ftp://ftp.ham-radio.ch/common/Screenshot-2012-06-01-203346.png
Simon Brown, HB9DRV
http://dit-dit-dit.com
Not sent from an iPhone: I don't have one and I don't want one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120601/57d8380a/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 1 Jun 2012 15:41:28 -0400
From: Shen Wenbo <[email protected]>
To: Weixian Zhou <[email protected]>
Cc: usrp-users <[email protected]>, [email protected]
Subject: Re: [USRP-users] Questions about benchmark_tx/benchmark_rx
Message-ID:
<caoakn9ag+9qmkshwbuqszsxy+rh927g_tjca8h9jadb0uon...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Fri, Jun 1, 2012 at 1:01 PM, Weixian Zhou <[email protected]> wrote:
> I used the benchmark_tx and benchmark_rx to transmit data and I have some
> questions:
> 1. I set the frequency of both benchmark_tx and benchmark_rx to 300M, the
> transmission succeed; but it failed when I set the frequency to 2.4G or
> other frequencies. Why is this?
>
What daughter board u are using, maybe your daughter board doesn't support
2.4GHz,
Target frequency: 300.000000 MHz
Actual frequency: 4500.000000 MHz
means u daughter board runs on 4.5GHz
> 2. Both the benchmark_tx and benchmark_rx gives the warning as I marked
> red: the actual frequency is not same but the transmission succeed. Why is
> it?
>
Target frequency: 300.000000 MHz
Actual frequency: 4500.000000 MHz
means u daughter board runs on 4.5GHz, maybe it doesn't support 300MHz
> 3. In the receiving end, the pktno is disordered some pktnos are much
> larger than averages. Why is it?
>
They are disrupted, so maybe some random numbers
4. What does the n_right=0 means? Does it mean the packet is corrupted in
> the receiving end?
>
n_right means how many packets are correctly received, which means their
crc check should be true (ok=True)
>
> *The benchmark_tx messages as following:*
> belltestbed@belltestbed-OptiPlex-790
> :~/Desktop/gnuradio/gr-digital/les/narrowband$ ./benchmark_tx.py -f 300M
> --from-file=pic.jpg
> linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.002-128-g12f7a5c9
>
> >>> gr_fir_ccf: using SSE
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
>
> UHD Warning:
> The recv buffer could not be resized sufficiently.
> Target sock buff size: 50000000 bytes.
> Actual sock buff size: 1000000 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.rmem_max=50000000
>
> UHD Warning:
> The recv buffer could not be resized sufficiently.
> Target sock buff size: 50000000 bytes.
> Actual sock buff size: 1000000 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.rmem_max=50000000
>
> UHD Warning:
> The send buffer could not be resized sufficiently.
> Target sock buff size: 1048576 bytes.
> Actual sock buff size: 1000000 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.wmem_max=1048576
>
> UHD Warning:
> Unable to set the thread priority. Performance may be negatively
> affected.
> Please see the general application notes in the manual for
> instructions.
> EnvironmentError: OSError: error in pthread_setschedparam
>
> No gain specified.
> Setting gain to 17.500000 (from [0.000000, 35.000000])
>
> UHD Warning:
> The hardware does not support the requested TX frequency:
> Target frequency: 300.000000 MHz
> Actual frequency: 4500.000000 MHz
>
> UHD Warning:
> The hardware does not support the requested TX sample rate:
> Target sample rate: 0.050000 MSps
> Actual sample rate: 0.195312 MSps
>
> Symbol Rate: 25000.000000
> Requested sps: 2.000000
> Given sample rate: 195312.500000
> Actual sps for rate: 7.812500
>
> Requested sample rate: 50000.000000
> Actual sample rate: 195312.500000
> Using Volk machine: avx_32
> Warning: failed to enable realtime scheduling
> .........................................................................
>
>
> *And the benchmark_rx messages as follwing:*
> bell@bell-HP-Compaq-4000-Pro-SFF-PC
> :~/Desktop/USRP/gnuradio/gr-digital/examples/narrowband$./benchmark_rx.py -f
> 300M
> linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.001-129-g23344268
>
> >>> gr_fir_ccf: using SSE
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
>
> UHD Warning:
> The recv buffer could not be resized sufficiently.
> Target sock buff size: 50000000 bytes.
> Actual sock buff size: 1000000 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.rmem_max=50000000
>
> UHD Warning:
> The recv buffer could not be resized sufficiently.
> Target sock buff size: 50000000 bytes.
> Actual sock buff size: 1000000 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.rmem_max=50000000
>
> UHD Warning:
> The send buffer could not be resized sufficiently.
> Target sock buff size: 1048576 bytes.
> Actual sock buff size: 1000000 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.wmem_max=1048576
>
> UHD Warning:
> Unable to set the thread priority. Performance may be negatively
> affected.
> Please see the general application notes in the manual for
> instructions.
> EnvironmentError: OSError: error in pthread_setschedparam
>
> No gain specified.
> Setting gain to 49.500000 (from [0.000000, 99.000000])
>
> UHD Warning:
> The hardware does not support the requested RX frequency:
> Target frequency: 300.000000 MHz
> Actual frequency: 2400.000000 MHz
>
> UHD Warning:
> The hardware does not support the requested RX sample rate:
> Target sample rate: 0.050000 MSps
> Actual sample rate: 0.195312 MSps
>
> Symbol Rate: 25000.000000
> Requested sps: 2.000000
> Given sample rate: 195312.500000
> Actual sps for rate: 7.812500
>
> Requested sample rate: 50000.000000
> Actual sample rate: 195312.500000
> Warning: Failed to enable realtime scheduling.
> Using Volk machine: ssse3_32
> ok = False pktno = 3850 n_rcvd = 1 n_right = 0
> ok = False pktno = 53042 n_rcvd = 2 n_right = 0
> ok = False pktno = 61454 n_rcvd = 3 n_right = 0
> ok = False pktno = 27 n_rcvd = 4 n_right = 0
> ok = False pktno = 41 n_rcvd = 5 n_right = 0
> ok = False pktno = 44 n_rcvd = 6 n_right = 0
> ok = False pktno = 44 n_rcvd = 7 n_right = 0
> ok = False pktno = 51 n_rcvd = 8 n_right = 0
> ok = False pktno = 43 n_rcvd = 9 n_right = 0
> ok = False pktno = 64 n_rcvd = 10 n_right = 0
>
>
> I am using two USRP N210.
>
> --
> Regards,
> Weixian Zhou
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
--
Wenbo
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120601/1478ec52/attachment-0001.html>
------------------------------
Message: 5
Date: Fri, 01 Jun 2012 12:52:45 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] WBX Frequency Response
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 06/01/2012 12:35 PM, Simon HB9DRV wrote:
> Hi All,
>
>
>
> After much keyboard pounding I've managed to get data from my WBX (Windows
> 7, 64-bit, Debug mode). Please look at the screenshot below, the sample rate
> ( using set_rx_rate() ) is 4MB. The response doesn't seem flat when the
> sample rate is anything above 2MB. Is this to be expected? I have set the RF
> Gain to the maximum of 38dB.
>
MB = megabytes
Msps = megasamples per second
>
>
> ftp://ftp.ham-radio.ch/common/Screenshot-2012-06-01-203346.png
>
Perhaps you are seeing the CIC filter rolloff. decimation =
100Msps/host_sample_rate. So for odd decimations, you get CIC filter and
no halfbands. Try an even decimation, you should see a flatter noise floor.
-josh
------------------------------
Message: 6
Date: Fri, 1 Jun 2012 22:00:56 +0200
From: "Simon HB9DRV" <[email protected]>
To: <[email protected]>, <[email protected]>
Subject: Re: [USRP-users] WBX Frequency Response
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Thanks Josh,
Using 5Ms/s sorted this problem.
Simon Brown, HB9DRV
http://dit-dit-dit.com
You are standing at the end of a road before a small brick building. Around
you is a forest.
A length of co-ax runs out of the building and down a gully.
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Josh Blum
Sent: 01 June 2012 21:53
To: [email protected]
Subject: Re: [USRP-users] WBX Frequency Response
On 06/01/2012 12:35 PM, Simon HB9DRV wrote:
> Hi All,
>
>
>
> After much keyboard pounding I've managed to get data from my WBX
> (Windows 7, 64-bit, Debug mode). Please look at the screenshot below,
> the sample rate ( using set_rx_rate() ) is 4MB. The response doesn't
> seem flat when the sample rate is anything above 2MB. Is this to be
> expected? I have set the RF Gain to the maximum of 38dB.
>
MB = megabytes
Msps = megasamples per second
>
>
> ftp://ftp.ham-radio.ch/common/Screenshot-2012-06-01-203346.png
>
Perhaps you are seeing the CIC filter rolloff. decimation =
100Msps/host_sample_rate. So for odd decimations, you get CIC filter and no
halfbands. Try an even decimation, you should see a flatter noise floor.
-josh
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 7
Date: Fri, 01 Jun 2012 23:18:43 -0700
From: John Malsbury <[email protected]>
To: [email protected], [email protected]
Subject: Re: [USRP-users] [Discuss-gnuradio] dc offset is different
from unit to unit
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
James,
In the case of DC calibration for tx, we'd recommend running the dc
calibration routines provided with UHD for each unit. The cal routines
make it a relatively easy process.
In theory, if the average DC offset is non-zero you may be able to apply
an average correction and see some improvement - but less than a
per-unit calibration. I don't have have any data on hand for an average
DC offset.
I'm cross-posting to the usrp-users list, which is more oriented to USRP
specific questions.
Best Regards
John Malsbury
On 6/1/2012 8:57 PM, James Jordan wrote:
> Hi list,
> I need to compensate usrp dc offset. but the dc offset is different
> from unit to unit. so do I need to calibrate each unit dc offset or
> there is a universal value that work
> for each unit?
>
> Regards
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
End of USRP-users Digest, Vol 22, Issue 2
*****************************************
