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: X310 transmit underflow when sampling rate is low
(Jonathon Pendlum)
2. Re: Clock Period Definitions of B210 (Ian Buckley)
3. Problems duplicating rfnoc_rxtx.grc radios for two UBX-160's
in an X310 (Swanson, Craig)
4. Continuous TX streaming (Cho, Daniel J (332C))
5. Re: Continuous TX streaming (Marcus M?ller)
6. Re: XCVR2450 dead (Michael West)
7. Re: XCVR2450 dead (Vladica Sark)
8. How to connect E312 to internet? (Xingjian Chen)
9. Re: How to connect E312 to internet? (Marcus M?ller)
10. Re: How to connect E312 to internet? (Philip Balister)
11. Re: How to connect E312 to internet? (Marcus M?ller)
12. Re: synchronization between N210 and X310 (Nicolas Cuervo)
13. PPS get_time_last_pps() (Dave NotTelling)
14. Ettus UBX-160 vs SBX-120 (Simon Olvhammar)
15. Frequency setting of USRP X300 with Basic TX (Bright Cheng)
16. Re: Ettus UBX-160 vs SBX-120 (Sylvain Munaut)
----------------------------------------------------------------------
Message: 1
Date: Tue, 27 Jun 2017 09:17:57 -0700
From: Jonathon Pendlum <[email protected]>
To: "Hood, Christopher L." <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 transmit underflow when sampling rate
is low
Message-ID:
<CAGdo0uQzV3HJCiBZsy=+NHoCpV=J6FUszGse_=176x=mpn2...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Chris,
What is your MTU size set to? How far into the future do you set the
timespec?
Jonathon
On Thu, Jun 22, 2017 at 2:12 PM, Hood, Christopher L. via USRP-users <
[email protected]> wrote:
> I?m running a simple one pulse loopback transmit/receive and am running
> into transmit underflows when the sampling rate is LOW. Specifically, for
> my short 30 us pulse, the underflow occurs when the sampling rate is 5 MHz
> or lower. I ran the test at 10, 20, 25, 33.3, 50, 100, and 200 MHz with no
> issues at all. The X310 is connected to the host over 10 gig Ethernet, and
> the tx stream send command is set with metadata so start of burst=1, end of
> burst=1, has time=1, and with the time spec well into the future wrt the
> device. The send command returns without incident, and when the time spec
> elapses, the async message is received, which indicates an underflow.
> Looking at the receive samples, the underflow appears to occur at the
> beginning of the intended transmission, because much of the intended
> waveform is being received.
>
>
>
> Any direction into fixing this issue would be appreciated.
>
>
>
> Thanks,
>
> chris
>
>
>
>
>
> _______________________________________________
> 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/20170627/3e64c65c/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 27 Jun 2017 10:42:19 -0700
From: Ian Buckley <[email protected]>
To: altu? kaya <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Clock Period Definitions of B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Altug,
All actual clocks are defined in timing.ucf for synthesis/timing analysis
purposes.
You should refer directly to the board schematics and RTL to understand exactly
what the signals you named actually do.
Note that it?s common in simulation to not use the actual clock frequencies
used in the real world, but rather synchronous fractions of a single root clock
frequency so that edge to edge timing between different clocks remains fixed,
avoiding setup/hold violations in logic that bridges clock domains.
-Ian
> On Jun 27, 2017, at 6:10 AM, altu? kaya via USRP-users
> <[email protected]> wrote:
>
> Hello everyone,
>
> I would like to simulate B210 and created a test bench for that. However, I
> do not know the exact values of cat_sclk_period, fx3_sclk_period,
> pll_sclk_period, debug_clk_period, IFCLK_period. Is there a way to find these
> values? Thank you.
>
> I am looking forward to your reply,
> Altug
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 3
Date: Tue, 27 Jun 2017 21:32:20 +0000
From: "Swanson, Craig" <[email protected]>
To: "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: [USRP-users] Problems duplicating rfnoc_rxtx.grc radios for
two UBX-160's in an X310
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Jonathon,
I am able to successfully run the flowgraph from the gr-ettus/examples/rfnoc
directory called rfnoc_rxtx.grc. This works great for a single UBX-160.
But if I have two daughtercards, I am running into two problems:
1) It needs two dmafifos. How do I instantiate two dmafifos?
2) I get errors where it seems to be unable to grab ddc_1 and duc_1. It errors
out because it says ddc_0 and duc_0 are already connected.
This is all happening with the HG or XG version of usrp_x310_fpga_HG.bit or
usrp_x310_fpga_RFNOC_HG.bit found in the images directory.
GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_4.0.0.rfnoc-devel-369-g1908672f]
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170627/01713ae5/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 27 Jun 2017 23:49:50 +0000
From: "Cho, Daniel J (332C)" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Continuous TX streaming
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hello,
Is it possible to continuously transmit stream without any breaks? Using the
"send" function provides a break at the end of the buffer which then loops back
and restarts the "send" function.
What I am looking for is a TX equivalent to the function below:
[cid:[email protected]]
My understanding is that this function can only be used for RX and cannot be
used for TX.
Thanks,
Daniel Cho
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170627/1b239ef4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 210884 bytes
Desc: image001.jpg
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170627/1b239ef4/attachment-0001.jpg>
------------------------------
Message: 5
Date: Wed, 28 Jun 2017 01:55:30 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Continuous TX streaming
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Dear Daniel,
Your application should call send() in a loop, each time giving it new
samples that will be sent immediately after the last samples. See our
examples (for example, tx_samples_from_file) in the uhd/host/examples
source code directory!
So, yes, continuous operation kind of is the default thing you do with
UHD :)
Best regards,
Marcus
On 28.06.2017 01:49, Cho, Daniel J (332C) via USRP-users wrote:
>
> Hello,
>
>
>
> Is it possible to continuously transmit stream without any breaks?
> Using the ?send? function provides a break at the end of the buffer
> which then loops back and restarts the ?send? function.
>
>
>
> What I am looking for is a TX equivalent to the function below:
>
> My understanding is that this function can only be used for RX and
> cannot be used for TX.
>
>
>
> Thanks,
>
> Daniel Cho
>
>
>
> _______________________________________________
> 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/20170628/f557d403/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 210884 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170628/f557d403/attachment-0001.jpg>
------------------------------
Message: 6
Date: Tue, 27 Jun 2017 19:58:06 -0700
From: Michael West <[email protected]>
To: Vladica Sark <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] XCVR2450 dead
Message-ID:
<cam4xkrqpmzbunzg18ukqs8hwcs0xer3zgfzb5xny73sxfpc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Vladica,
The boards are most likely fine. We found a recent issue in the latest
version of UHD that causes the issue you are seeing. It was introduced in
commit 6092064
<https://github.com/EttusResearch/uhd/commit/60920644aa33d1a6f7a4dac30bdb890b9bc4301f#diff-f2ea86e1c3a18233d1a4940c095c638c>
and fixed in commit f0b3283
<https://github.com/EttusResearch/uhd/commit/f0b328360d6a89c2541463feaf90589e5848f5b9#diff-f2ea86e1c3a18233d1a4940c095c638c>,
so any build between those will have the problem. Using the head of the
maint or UHD-3.9.LTS branches will work just fine.
Regards,
Michael
On Tue, Feb 21, 2017 at 10:11 PM, Vladica Sark via USRP-users <
[email protected]> wrote:
> Hi Martin,
>
> One board was not installed in a usrp. When installed it was dead. The
> other was working inside a usrp and after a while, i.e. couple of months it
> also died. The usrp was not opened in meanwhile. The only thing that might
> happen, is that my colleagues changed antennas and nothing more than that.
>
> We would try to change the RF chip. Hopefully this would fix the board if
> the other chips are ok.
>
> What surprises me is that the eeprom is deleted and at the same time the
> RF chip is dead. They are almost completely separated.
>
> BR,
> Vladica
>
>
>
> On 22.02.2017 01:10, Martin Braun via USRP-users wrote:
>
>> Vladica,
>>
>> do other boards work fine? This is not the expected behaviour. How did
>> you fry your board? Maybe something got permanently damaged.
>>
>> -- M
>>
>> On 02/20/2017 04:13 AM, Vladica Sark via USRP-users wrote:
>>
>>> Hi there,
>>>
>>> I have two XCVR2450 that died. Their eeprom gets first erased. When I
>>> reprogram the eeprom, the N210 recognizes them, but I never get a pll
>>> lock. Also when I acquire samples they are almost zero. I do not know if
>>> the both boards died on the same radio, since I have a few N210s.
>>>
>>> Has anybody had such experience with XCVR240 and N210?
>>>
>>> Here is the data from probing a dead XCVR2450:
>>>
>>> UHD Error:
>>> The daughterboard manager encountered a recoverable error in init.
>>> Loading the "unknown" daughterboard implementations to continue.
>>> The daughterboard cannot operate until this error is resolved.
>>> AssertionError: assertion failed:
>>> 1041666.6666666666 is not a valid tx dboard clock rate.
>>> possible values are: [100000000, 50000000, 33333333.333333332,
>>> 25000000, 20000000, 16666666.666666666, 14285714.285714285, 12500000,
>>> 11111111.111111112, 10000000, 9090909.0909090918, 8333333.333333333,
>>> 7692307.692307692, 7142857.1428571427, 6666666.666666667, 6250000,
>>> 5882352.9411764704, 5555555.555555556, 5263157.8947368423, 5000000,
>>> 4761904.7619047621, 4545454.5454545459, 4347826.0869565215,
>>> 4166666.6666666665, 4000000, 3846153.846153846, 3703703.7037037038,
>>> 3571428.5714285714, 3448275.8620689656, 3333333.3333333335,
>>> 3225806.4516129033, 3125000].
>>> _____________________________________________________
>>> /
>>> | Device: USRP2 / N-Series Device
>>> | _____________________________________________________
>>> | /
>>> | | Mboard: N210r4
>>> | | hardware: 2577
>>> | | mac-addr: (intentionally removed)
>>> | | ip-addr: 192.168.10.3
>>> | | subnet: 255.255.255.255
>>> | | gateway: 255.255.255.255
>>> | | gpsdo: none
>>> | | serial: (intentionally removed)
>>> | | FW Version: 12.4
>>> | | FPGA Version: 11.1
>>> | |
>>> | | Time sources: none, external, _external_, mimo
>>> | | Clock sources: internal, external, mimo
>>> | | Sensors: mimo_locked, ref_locked
>>> | | _____________________________________________________
>>> | | /
>>> | | | RX DSP: 0
>>> | | |
>>> | | | Freq range: -50.000 to 50.000 MHz
>>> | | _____________________________________________________
>>> | | /
>>> | | | RX DSP: 1
>>> | | |
>>> | | | Freq range: -50.000 to 50.000 MHz
>>> | | _____________________________________________________
>>> | | /
>>> | | | RX Dboard: A
>>> | | | ID: XCVR2450, XCVR2450 - r2.1 (0x0061)
>>> | | | Serial: F48955
>>> | | | _____________________________________________________
>>> | | | /
>>> | | | | RX Frontend: 0
>>> | | | | Name: Unknown (0xffff) - 0
>>> | | | | Antennas:
>>> | | | | Sensors:
>>> | | | | Freq range: 0.000 to 0.000 MHz
>>> | | | | Gain Elements: None
>>> | | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz
>>> | | | | Connection Type: IQ
>>> | | | | Uses LO offset: No
>>> | | | _____________________________________________________
>>> | | | /
>>> | | | | RX Codec: A
>>> | | | | Name: ads62p44
>>> | | | | Gain range digital: 0.0 to 6.0 step 0.5 dB
>>> | | | | Gain range fine: 0.0 to 0.5 step 0.1 dB
>>> | | _____________________________________________________
>>> | | /
>>> | | | TX DSP: 0
>>> | | |
>>> | | | Freq range: -50.000 to 50.000 MHz
>>> | | _____________________________________________________
>>> | | /
>>> | | | TX Dboard: A
>>> | | | ID: XCVR2450 - r2.1 (0x0059)
>>> | | | Serial: F48955
>>> | | | _____________________________________________________
>>> | | | /
>>> | | | | TX Frontend: 0
>>> | | | | Name: Unknown (0xffff) - 0
>>> | | | | Antennas:
>>> | | | | Sensors:
>>> | | | | Freq range: 0.000 to 0.000 MHz
>>> | | | | Gain Elements: None
>>> | | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz
>>> | | | | Connection Type: IQ
>>> | | | | Uses LO offset: No
>>> | | | _____________________________________________________
>>> | | | /
>>> | | | | TX Codec: A
>>> | | | | Name: ad9777
>>> | | | | Gain Elements: None
>>>
>>> BR,
>>> Vladica
>>>
>>> _______________________________________________
>>> 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
>>
>>
> _______________________________________________
> 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/20170627/cfcf38d4/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 28 Jun 2017 08:04:20 +0200
From: Vladica Sark <[email protected]>
To: Michael West <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] XCVR2450 dead
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Thanks Michael,
I had the feeling that there is some issue with the software. We
reprogrammed the board eeproms and changed the RF chip but everything
stayed the same. I thought that a wrong configuration is written to the
RF chip, but I didn't had time to investigate the problem further.
I would try to install the boards these days.
BR,
Vladica
On 28.06.2017 04:58, Michael West wrote:
> Hi Vladica,
>
> The boards are most likely fine. We found a recent issue in the latest
> version of UHD that causes the issue you are seeing. It was introduced
> in commit 6092064
> <https://github.com/EttusResearch/uhd/commit/60920644aa33d1a6f7a4dac30bdb890b9bc4301f#diff-f2ea86e1c3a18233d1a4940c095c638c>
>
> and fixed in commit f0b3283
> <https://github.com/EttusResearch/uhd/commit/f0b328360d6a89c2541463feaf90589e5848f5b9#diff-f2ea86e1c3a18233d1a4940c095c638c>,
>
> so any build between those will have the problem. Using the head of the
> maint or UHD-3.9.LTS branches will work just fine.
>
> Regards,
> Michael
>
> On Tue, Feb 21, 2017 at 10:11 PM, Vladica Sark via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi Martin,
>
> One board was not installed in a usrp. When installed it was dead.
> The other was working inside a usrp and after a while, i.e. couple
> of months it also died. The usrp was not opened in meanwhile. The
> only thing that might happen, is that my colleagues changed antennas
> and nothing more than that.
>
> We would try to change the RF chip. Hopefully this would fix the
> board if the other chips are ok.
>
> What surprises me is that the eeprom is deleted and at the same time
> the RF chip is dead. They are almost completely separated.
>
> BR,
> Vladica
>
>
>
> On 22.02.2017 01 <tel:22.02.2017%2001>:10, Martin Braun via
> USRP-users wrote:
>
> Vladica,
>
> do other boards work fine? This is not the expected behaviour.
> How did
> you fry your board? Maybe something got permanently damaged.
>
> -- M
>
> On 02/20/2017 04:13 AM, Vladica Sark via USRP-users wrote:
>
> Hi there,
>
> I have two XCVR2450 that died. Their eeprom gets first
> erased. When I
> reprogram the eeprom, the N210 recognizes them, but I never
> get a pll
> lock. Also when I acquire samples they are almost zero. I do
> not know if
> the both boards died on the same radio, since I have a few
> N210s.
>
> Has anybody had such experience with XCVR240 and N210?
>
> Here is the data from probing a dead XCVR2450:
>
> UHD Error:
> The daughterboard manager encountered a recoverable
> error in init.
> Loading the "unknown" daughterboard implementations to
> continue.
> The daughterboard cannot operate until this error is
> resolved.
> AssertionError: assertion failed:
> 1041666.6666666666 is not a valid tx dboard clock rate.
> possible values are: [100000000, 50000000,
> 33333333.333333332,
> 25000000, 20000000, 16666666.666666666, 14285714.285714285,
> 12500000,
> 11111111.111111112, 10000000, 9090909.0909090918,
> 8333333.333333333,
> 7692307.692307692, 7142857.1428571427, 6666666.666666667,
> 6250000,
> 5882352.9411764704, 5555555.555555556, 5263157.8947368423,
> 5000000,
> 4761904.7619047621, 4545454.5454545459, 4347826.0869565215,
> 4166666.6666666665, 4000000, 3846153.846153846,
> 3703703.7037037038 <tel:7037037038>,
> 3571428.5714285714 <tel:5714285714>, 3448275.8620689656,
> 3333333.3333333335,
> 3225806.4516129033, 3125000].
> _____________________________________________________
> /
> | Device: USRP2 / N-Series Device
> | _____________________________________________________
> | /
> | | Mboard: N210r4
> | | hardware: 2577
> | | mac-addr: (intentionally removed)
> | | ip-addr: 192.168.10.3
> | | subnet: 255.255.255.255
> | | gateway: 255.255.255.255
> | | gpsdo: none
> | | serial: (intentionally removed)
> | | FW Version: 12.4
> | | FPGA Version: 11.1
> | |
> | | Time sources: none, external, _external_, mimo
> | | Clock sources: internal, external, mimo
> | | Sensors: mimo_locked, ref_locked
> | | _____________________________________________________
> | | /
> | | | RX DSP: 0
> | | |
> | | | Freq range: -50.000 to 50.000 MHz
> | | _____________________________________________________
> | | /
> | | | RX DSP: 1
> | | |
> | | | Freq range: -50.000 to 50.000 MHz
> | | _____________________________________________________
> | | /
> | | | RX Dboard: A
> | | | ID: XCVR2450, XCVR2450 - r2.1 (0x0061)
> | | | Serial: F48955
> | | |
> _____________________________________________________
> | | | /
> | | | | RX Frontend: 0
> | | | | Name: Unknown (0xffff) - 0
> | | | | Antennas:
> | | | | Sensors:
> | | | | Freq range: 0.000 to 0.000 MHz
> | | | | Gain Elements: None
> | | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz
> | | | | Connection Type: IQ
> | | | | Uses LO offset: No
> | | |
> _____________________________________________________
> | | | /
> | | | | RX Codec: A
> | | | | Name: ads62p44
> | | | | Gain range digital: 0.0 to 6.0 step 0.5 dB
> | | | | Gain range fine: 0.0 to 0.5 step 0.1 dB
> | | _____________________________________________________
> | | /
> | | | TX DSP: 0
> | | |
> | | | Freq range: -50.000 to 50.000 MHz
> | | _____________________________________________________
> | | /
> | | | TX Dboard: A
> | | | ID: XCVR2450 - r2.1 (0x0059)
> | | | Serial: F48955
> | | |
> _____________________________________________________
> | | | /
> | | | | TX Frontend: 0
> | | | | Name: Unknown (0xffff) - 0
> | | | | Antennas:
> | | | | Sensors:
> | | | | Freq range: 0.000 to 0.000 MHz
> | | | | Gain Elements: None
> | | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz
> | | | | Connection Type: IQ
> | | | | Uses LO offset: No
> | | |
> _____________________________________________________
> | | | /
> | | | | TX Codec: A
> | | | | Name: ad9777
> | | | | Gain Elements: None
>
> BR,
> Vladica
>
> _______________________________________________
> 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>
>
>
>
> _______________________________________________
> 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>
>
>
> _______________________________________________
> 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>
>
>
------------------------------
Message: 8
Date: Wed, 28 Jun 2017 09:36:50 +0000
From: Xingjian Chen <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] How to connect E312 to internet?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
Does any one know how to make an USRP E312 internet accessible? I would like to
download and install some package such as tmux in it. Thank you.
Microwave Remote Sensing Laboratory
Electrical and Computer Engineering
Univeristy of Massachusetts, Amherst
PhD Student
Xingjian Chen
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170628/92426687/attachment-0001.html>
------------------------------
Message: 9
Date: Wed, 28 Jun 2017 13:04:10 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] How to connect E312 to internet?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Dear Xingjian,
the E312 is an embedded device. While you can just connect it to any
network like you could connect any other Linux computer, it is not meant
to be used in a manner like e.g. a Ubuntu PC.
You can save yourself the effort of getting tmux if you're just as
comfortable using "screen" instead, which is a very similar (albeit
somewhat older) piece of software, already included in your SD Card image.
You'll need to cross-compile the software you want to use on the E312
and transfer it onto the E312 yourself. There's two approaches here:
* use the SDK (recommended): The SDK contains all compilers that were
used to build the SD card image you're using on the E312. That
means: you just get the TMUX source code and build it using the SDK.
If tmux has dependencies that aren't already part of the SD card
image, and hence, the SDK, you'll have to build these dependencies
first, and then build tmux. However, I think tmux only needs
libevent and ncurses, and both should be included already.
* build your own SD Card image (more work, more complications): use
the OpenEmbedded system that we use to build the E312 SD Card
images, but modify it to include a "recipe" (or "layer") for the
software you want (in this case, tmux). If someone from the
OpenEmbedded/Yocto community has already taken the effort to write
such an addition, that modification should be straightforward, and
all you have to do is set up a VM to build in, follow the
instructions, start the bitbake and sit back and relax for >>1h.
As said, in your use case, I'd recommend taking the SDK route. Both
methods are described in
https://files.ettus.com/manual/page_usrp_e3x0.html
Best regards,
Marcus
On 28.06.2017 11:36, Xingjian Chen via USRP-users wrote:
>
> Hi,
>
> Does any one know how to make an USRP E312 internet accessible? I
> would like to download and install some package such as tmux in it.
> Thank you.
>
>
> Microwave Remote Sensing Laboratory
>
> Electrical and Computer Engineering
>
> Univeristy of Massachusetts, Amherst
>
> PhD Student
>
> Xingjian Chen
>
>
>
> _______________________________________________
> 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/20170628/e4543475/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 28 Jun 2017 07:46:27 -0400
From: Philip Balister <[email protected]>
To: Marcus M?ller <[email protected]>,
[email protected]
Subject: Re: [USRP-users] How to connect E312 to internet?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 06/28/2017 07:04 AM, Marcus M?ller via USRP-users wrote:
> Dear Xingjian,
>
>
> the E312 is an embedded device. While you can just connect it to any
> network like you could connect any other Linux computer, it is not meant
> to be used in a manner like e.g. a Ubuntu PC.
>
>
> You can save yourself the effort of getting tmux if you're just as
> comfortable using "screen" instead, which is a very similar (albeit
> somewhat older) piece of software, already included in your SD Card image.
>
>
> You'll need to cross-compile the software you want to use on the E312
> and transfer it onto the E312 yourself. There's two approaches here:
>
>
> * use the SDK (recommended): The SDK contains all compilers that were
> used to build the SD card image you're using on the E312. That
> means: you just get the TMUX source code and build it using the SDK.
> If tmux has dependencies that aren't already part of the SD card
> image, and hence, the SDK, you'll have to build these dependencies
> first, and then build tmux. However, I think tmux only needs
> libevent and ncurses, and both should be included already.
> * build your own SD Card image (more work, more complications): use
> the OpenEmbedded system that we use to build the E312 SD Card
> images, but modify it to include a "recipe" (or "layer") for the
> software you want (in this case, tmux). If someone from the
> OpenEmbedded/Yocto community has already taken the effort to write
> such an addition, that modification should be straightforward, and
> all you have to do is set up a VM to build in, follow the
> instructions, start the bitbake and sit back and relax for >>1h.
>
> As said, in your use case, I'd recommend taking the SDK route. Both
> methods are described in
And I'd just build anew image :)
Checking the layer index shows that there is a tmux recipe (for the
jethro release) in meta-oe, so it should be fairly straightforward to add.
http://layers.openembedded.org/layerindex/branch/jethro/recipes/?q=tmux
Philip
>
>
> https://files.ettus.com/manual/page_usrp_e3x0.html
>
>
> Best regards,
> Marcus
>
> On 28.06.2017 11:36, Xingjian Chen via USRP-users wrote:
>>
>> Hi,
>>
>> Does any one know how to make an USRP E312 internet accessible? I
>> would like to download and install some package such as tmux in it.
>> Thank you.
>>
>>
>> Microwave Remote Sensing Laboratory
>>
>> Electrical and Computer Engineering
>>
>> Univeristy of Massachusetts, Amherst
>>
>> PhD Student
>>
>> Xingjian Chen
>>
>>
>>
>> _______________________________________________
>> 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: 11
Date: Wed, 28 Jun 2017 13:52:47 +0200
From: Marcus M?ller <[email protected]>
To: Philip Balister <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] How to connect E312 to internet?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hey Phil :)
I'd do that, too! But:
Well, you do have both the build infrastructure ready and experience on
how to use OE.
But people that never done that first have to go through getting a VM
with a GCC version that works for this build, then follow the
instructions on the wiki, do a 2h plain build to see whether it really
works without modifications, then learn how to integrate a layer into OE
and in which place, and then do another build, and then integrate
whatever they've already got on data and configs on the E312 into that
image.
I agree, it's the cleaner and easier-to-long-term-maintain solution, but
meh, economics of effort say: that's why OE folks/you go through the
effort of getting the SDK as a side product of an OE build, isn't it?
Cheers,
Marcus
On 28.06.2017 13:46, Philip Balister wrote:
> On 06/28/2017 07:04 AM, Marcus M?ller via USRP-users wrote:
>> Dear Xingjian,
>>
>>
>> the E312 is an embedded device. While you can just connect it to any
>> network like you could connect any other Linux computer, it is not meant
>> to be used in a manner like e.g. a Ubuntu PC.
>>
>>
>> You can save yourself the effort of getting tmux if you're just as
>> comfortable using "screen" instead, which is a very similar (albeit
>> somewhat older) piece of software, already included in your SD Card image.
>>
>>
>> You'll need to cross-compile the software you want to use on the E312
>> and transfer it onto the E312 yourself. There's two approaches here:
>>
>>
>> * use the SDK (recommended): The SDK contains all compilers that were
>> used to build the SD card image you're using on the E312. That
>> means: you just get the TMUX source code and build it using the SDK.
>> If tmux has dependencies that aren't already part of the SD card
>> image, and hence, the SDK, you'll have to build these dependencies
>> first, and then build tmux. However, I think tmux only needs
>> libevent and ncurses, and both should be included already.
>> * build your own SD Card image (more work, more complications): use
>> the OpenEmbedded system that we use to build the E312 SD Card
>> images, but modify it to include a "recipe" (or "layer") for the
>> software you want (in this case, tmux). If someone from the
>> OpenEmbedded/Yocto community has already taken the effort to write
>> such an addition, that modification should be straightforward, and
>> all you have to do is set up a VM to build in, follow the
>> instructions, start the bitbake and sit back and relax for >>1h.
>>
>> As said, in your use case, I'd recommend taking the SDK route. Both
>> methods are described in
> And I'd just build anew image :)
>
> Checking the layer index shows that there is a tmux recipe (for the
> jethro release) in meta-oe, so it should be fairly straightforward to add.
>
> http://layers.openembedded.org/layerindex/branch/jethro/recipes/?q=tmux
>
> Philip
>
>>
>> https://files.ettus.com/manual/page_usrp_e3x0.html
>>
>>
>> Best regards,
>> Marcus
>>
>> On 28.06.2017 11:36, Xingjian Chen via USRP-users wrote:
>>> Hi,
>>>
>>> Does any one know how to make an USRP E312 internet accessible? I
>>> would like to download and install some package such as tmux in it.
>>> Thank you.
>>>
>>>
>>> Microwave Remote Sensing Laboratory
>>>
>>> Electrical and Computer Engineering
>>>
>>> Univeristy of Massachusetts, Amherst
>>>
>>> PhD Student
>>>
>>> Xingjian Chen
>>>
>>>
>>>
>>> _______________________________________________
>>> 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: 12
Date: Wed, 28 Jun 2017 14:50:13 +0200
From: Nicolas Cuervo <[email protected]>
To: john liu <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] synchronization between N210 and X310
Message-ID:
<CAOuPCvja=8kzxt-czt6x3f+cqpa37invtqlwevczrzayrgw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello John,
Synchronization between your devices should be a straightforward procedure
following the common steps [1], and the N210 and X310 are devices well
suited for this task, as you can see in the table 4 - "Recommended Models
for MIMO Systems" at [2]. Just a couple of remarks here:
1. As they are devices from different "family", you should not try to use
group them into a mult_usrp object, as that is only supported for devices
of the same type [3].
2. You will be safe trying to achieve time and frequency synchronization.
However, for phase synchronization, there are multiple factors [4] that
will come in your way if you try to perform this. Because of this, this is
not supported for the configuration you are describing.
Regards,
- Nicolas
[1] https://files.ettus.com/manual/page_sync.html
[2]
https://kb.ettus.com/Selecting_an_USRP_Device#USRP_Device_Characteristics
[3] https://files.ettus.com/manual/page_multiple.html
[4]
https://kb.ettus.com/Synchronization_and_MIMO_Capability_with_USRP_Devices#Other_Variables_That_Effect_Phase_Alignment
On Tue, Jun 27, 2017 at 11:31 AM, john liu via USRP-users <
[email protected]> wrote:
> Hi,all,
> Could we achieve synchronization between N210 and X310 with gpsdo(or
> octoclock)? If yes,
> MIMO will be OK?
>
> best regards
> John
>
> _______________________________________________
> 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/20170628/0892e03b/attachment-0001.html>
------------------------------
Message: 13
Date: Wed, 28 Jun 2017 09:04:48 -0400
From: Dave NotTelling <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] PPS get_time_last_pps()
Message-ID:
<cak6gvuo-hxvux01a76qjoe2rd5pgjnp7kxnbg97zrkwjgkx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I just recently hooked my N210 up to a 1 PPS source and was expecting that
calls to radio->get_time_last_pps() would return a number really close to 1
second from the previous call. Instead I get the following:
[output]
$ g++ t.cc -o t -luhd -lboost_thread -lboost_system && ./t
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.009.004-0-gfb928f42
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
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
0.000012
0.000024
0.000035
0.000047
0.000059
0.000071
0.000083
0.000094
0.000106
0.000118
0.000130
0.000142
0.000153
0.000165
0.000177
0.000189
[/output]
The drift is fairly constant at ~ 11-12 us per second. It should be noted
that I am not using a 10 MHz reference. Just the 1 PPS.
Here is the code I'm using:
[code]
#include <boost/thread.hpp>
#include <uhd/usrp/multi_usrp.hpp>
int main(){
uhd::usrp::multi_usrp::sptr radio =
uhd::usrp::multi_usrp::make(std::string("addr=192.168.12.2"));
radio->set_time_source("external");
radio->set_time_next_pps(uhd::time_spec_t(0, 0));
boost::this_thread::sleep_for(boost::chrono::seconds(2));
while(1){
uhd::time_spec_t t = radio->get_time_last_pps();
fprintf(stderr, "%0.6f\n", t.get_frac_secs());
boost::this_thread::sleep_for(boost::chrono::seconds(1));
}
}
[/code]
And here is the output of the test_pps_input command:
[output]
$ /tmp/test_pps_input --args addr=192.168.12.2
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.009.004-0-gfb928f42
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
Creating the usrp device with: addr=192.168.12.2...
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
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
Using Device: Single USRP:
Device: USRP2 / N-Series Device
Mboard 0: N210r4
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: UBX RX
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: UBX TX
Attempt to detect the PPS and set the time...
-- 1) catch time transition at pps edge
-- 2) set times next pps (synchronously)
Success!
[/output]
Am I doing something wrong?
Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170628/0791f86f/attachment-0001.html>
------------------------------
Message: 14
Date: Wed, 28 Jun 2017 09:30:42 +0200
From: Simon Olvhammar <[email protected]>
To: [email protected]
Subject: [USRP-users] Ettus UBX-160 vs SBX-120
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
We currently running a system with a Ettus x310 and a SBX-120.
We also a have UBX-160 daughter board.
For several reasons, mainly due to computer performance limitations, we
can only run with a complex sampling rate of 120 MHz.
My question is if I will see any improvement in performance, e.g. filter
characteristics, if I instead use the UBX-160 and run it at 120 MHz
compared to SBX-120 at 120 MHz or are they similar?
Best regards
Simon
------------------------------
Message: 15
Date: Tue, 27 Jun 2017 10:18:12 +0800
From: Bright Cheng <[email protected]>
To: [email protected]
Subject: [USRP-users] Frequency setting of USRP X300 with Basic TX
Message-ID:
<CAHQVGEgmOmkX2oyUg6UHwNTA2ecpeiuQ2TG8WzXFsbhxh16=6...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I am testing X300 with Basic TX.
When I use "tx_waveform" to generate waveform at 220MHz, the "Actual TX
Freq" displayed is 20.0 MHz.
How can I actually configure the device to generate waveform at 220MHz?
Thank so much.
Best regards.
Bright
ubuntu@ubuntu:/usr/local/lib/uhd/examples$ sudo ./tx_waveforms --freq 220e6
--subdev "B:AB" --rate 10e6
linux; GNU C++ version 4.8.4; Boost_105400; UHD_3.11.0.git-71-g2016126f
Creating the usrp device with: ...
-- X300 initialization sequence...
--
-- Thread ID 7f61ce50f780 for motherboard 0
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1184.0MB/s)
-- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1184.3MB/s)
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
Using Device: Single USRP:
Device: X-Series Device
Mboard 0: X300
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: CBX-120 RX
RX Channel: 1
RX DSP: 0
RX Dboard: B
RX Subdev: BasicRX (AB)
TX Channel: 0
TX DSP: 0
TX Dboard: B
TX Subdev: BasicTX (AB)
Setting TX Rate: 10.000000 Msps...
Actual TX Rate: 10.000000 Msps...
Setting TX Freq: 220.000000 MHz...
Actual TX Freq: 20.000000 MHz...
Setting device timestamp to 0...
Press Ctrl + C to stop streaming...
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170627/bf330d0c/attachment-0001.html>
------------------------------
Message: 16
Date: Wed, 28 Jun 2017 16:12:02 +0200
From: Sylvain Munaut <[email protected]>
To: Simon Olvhammar <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Ettus UBX-160 vs SBX-120
Message-ID:
<cahl+j08jduww4bbe80dwmgdvvrsnhkupkodvzmfrhhfgrmh...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi,
> We currently running a system with a Ettus x310 and a SBX-120.
> We also a have UBX-160 daughter board.
>
> For several reasons, mainly due to computer performance limitations, we can
> only run with a complex sampling rate of 120 MHz.
> My question is if I will see any improvement in performance, e.g. filter
> characteristics, if I instead use the UBX-160 and run it at 120 MHz compared
> to SBX-120 at 120 MHz or are they similar?
You can't do that.
If you have the master clock-rate at 120 MHz and use a 160 MHz wide
daugtherboard, you will get aliasing because the ADC are too slow.
You'd have to go to a 100 MHz samplerate for it to work. (200 MHz
sampled by the ADC then HW decimated by 2 to 100 Msps).
Cheers,
Sylvain
------------------------------
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 27
******************************************
