v spec to "A:0", and TX subdev spec to "B:0". This will
select the A-side for RX, and the B-side for TX. Then, create one
streamer on channel 0 for each direction (call get_rx_stream() and
get_tx_stream() with default args).
2. Set the RX and TX subdev spec both to "A:0 B:0" (this is the
default). Then, call get_rx_stream() with channels = [0] and
get_tx_stream() with channels = [1] (both are vectors of length one).
Both will achieve the same effect. The difference is when calling other
multi_usrp calls such as set_rx_freq() or set_tx_freq(). The channel
indexing is relative to the subdev spec.
-- Martin
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20180123/fa159c28/attachment-0001.asc>
--
Message: 8
Date: Tue, 23 Jan 2018 10:11:18 -0800
From: Martin Braun
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] 2 B210 synchronous problem
Message-ID: <20180123181118.GC25817@glad0s>
Content-Type: text/plain; charset="utf-8"
On Thu, Jan 18, 2018 at 10:34:14AM +0100, Piotr Krysik via USRP-users wrote:
> Hi Hideyuki,
>
> Our students were working (with my help) on synchronizing two USRPs B210
> with use of Octoclock-G.
> To make your code work without any race-conditions I would add a loop
> that waits for pps edge before your adjustment code, like this:
> ```
> ? time_last_pps = self.uhd_usrp_source_0.get_time_last_pps()
> ? while(self.uhd_usrp_source_0.get_time_last_pps() == time_last_pps):
> ??? time.sleep(0.01)
> ```
This is good advice. You can go to multi_usrp.cpp and take a look at
set_time_unknown_pps() for a reference on how to do that.
-- Martin
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20180123/19512338/attachment-0001.asc>
--------------
Message: 9
Date: Tue, 23 Jan 2018 10:18:41 -0800
From: Martin Braun
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP with different GPSDO
Message-ID: <20180123181841.GA32667@glad0s>
Content-Type: text/plain; charset="us-ascii"
On Tue, Jan 23, 2018 at 01:47:57PM +0300, Ali via USRP-users wrote:
>Hi to all,
>Is it possible to use different GPSDO (more accurate) than the one that
>Ettus sells? The device is X310. Can you suggest any brand or model?
>Best,
Ali,
if you find a pin- and API-compatible GPSDO, you can give it a try, but
keep in mind that's outside of what warranty and support covers.
-- Martin
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20180123/bdcd506a/attachment-0001.asc>
--
Message: 10
Date: Tue, 23 Jan 2018 10:22:13 -0800
From: Martin Braun
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Passing Messages as Commands to UHD Sink
Message-ID: <20180123182213.GB32667@glad0s>
Content-Type: text/plain; charset="utf-8"
On Tue, Jan 23, 2018 at 02:11:21AM +, Sarah Tran via USRP-users wrote:
>Hi All,
>
>I would like to change the center freq of my UHD Sink depending on who the
>receiver is. So I wrote a custom block that will read what the destination
>mac address is for a packet, and send a message to change the center freq
>based on what destination address it is. This is the format for how I
>write the message:
>
>{
> message_port_register_out(PDU_PORT_ID);
>}
> command = pmt::make_dict();
> command = pmt::dict_add(command, pmt::mp(?freq?),
>pmt::mp(2.412e9));
> command = pmt::dict_add(command, pmt::mp(?chan?),
>pmt::mp(0));
> message_port_pub(PDU_PORT_ID, command);
>
>I saw from other mailing list posts, that this was the syntax they used,
>but I can?t get it to actually the center frequency. Is there something I
>am doing wrong? I am using uhd version 3.10 and GRC version 3.7.11.1.
Sarah,
this looks fine. Are you sure the messages are being received? Do you
see any log statements to that effect?
-- Martin
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20180123/33987d8c/attachment-0001
