I believe if you don't set the end of burst flag it won't reset the accumulator.

On another note, how difficult would it be to reset the accumulator at the start of burst.  While doing it at the end makes it coherent with itself, the xmit waveform still has a starting phase change from pulse to pulse.  Typically we would reset it at the beginning ( or initialize it to a known phase ) at the beginning of the pulse so that it can be controlled regardless of timing.


Mike


On 05/29/2019 09:17 PM, Marcus D. Leech via USRP-users wrote:
On 05/29/2019 06:49 PM, Michael West via USRP-users wrote:
Thanks to Michael's persistence, we did find an issue in the DUC and DDC where the phase accumulator was the wrong resolution (24-bit instead of 32-bit) and was not being reset at the end of each burst.  The fix is now available on the head of the UHD-3.14 branch and will be included in the upcoming 3.14.1.0 release.

Phase may change each time streamers are created, but the phase between TX and RX should remain consistent during streaming.  Tuning must be done with timed commands and a consistent time delta between the tune time of TX and RX must be maintained that is greater than 500us to maintain the coherence across re-tunes.

Regards,
Michael
My recollection is that there are a class of users who want the phase accumulator to continue to spin between bursts.  So this fix may break
  other types of applications.  Just a dim recollection at this point....



On Tue, Apr 9, 2019 at 12:21 AM Piotr Krysik via USRP-users <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:

    Hi Mike,

    Let's keep the discussion on the mailing list. I attach the
    scripts as
    they are quite small. There is however a data folder with two 4MB
    files
    containing noise in complex short format. The version of the archive
    with those files is here:
    https://app.box.com/s/xfpwro8wybog4f1yo1l6yh665tg4sx0r

    First you run:
    ./record.sh

    then:
    ./show_figures.m

    (you need to have octave installed for the second script).

    Best Regards,
    Piotr Krysik

    W dniu 08.04.2019 o 18:30, Michael R. Freedman pisze:
    > That would be wonderful if I could get your scripts to run.
    >
    >
    > Thanks a bunch for the info!
    >
    >
    > Mike
    >
    >
    > On 04/08/2019 09:56 AM, Piotr Krysik via USRP-users wrote:
    >> Hi all,
    >>
    >> I looked at this thread and it reminded me of something.
    >>
    >> Once we purchased few X310 with UBX160 daughter-boards.
    >>
    >> One of them had some frequency offset on Tx channel, that
    decreased over
    >> time it was running, but very slowly.
    >>
    >> The daughter-board was then replaced by National Intruments
    (after some
    >> adventures ;) ). The replacement one had exactly the same
    issue so it
    >> was also replaced. The next one was ok. So it seemed it was some
    >> manufacturing issue with UBX.
    >>
    >> I don't know if it's the same issue (i.e. due to lack of
    data), but I
    >> attach part of the report that was sent to National Instruments:
    >> -phase offset of the received signal in relation to digital
    waveform for
    >> a single X310 with UBX160 for all TX and RX combinations:
    >> https://imgur.com/a/ODBtT4o
    >> -schematic:
    >> https://imgur.com/a/si9fJZp
    >>
    >> I got also scripts that were used for recording and plotting that
    >> figure. If you are interested I can post it somewhere.
    >>
    >> What seems different from situation here is that for us it
    seemed the
    >> effect wasn't depending on frequency (but I didn't do any
    extensive
    >> tests and might not remember).
    >>
    >> --
    >> Best Regards,
    >> Piotr Krysik
    >>
    >> W dniu 07.04.2019 o 03:00, Freedman, Michael - 1008 - MITLL via
    >> USRP-users pisze:
    >>> I have switched and am currently running the release 3.14.0.0
    >>>
    >>> Sent from my iPhone
    >>>
    >>> On Apr 6, 2019, at 8:58 AM, Marcus D. Leech
    <patchvonbr...@gmail.com <mailto:patchvonbr...@gmail.com>
    >>> <mailto:patchvonbr...@gmail.com
    <mailto:patchvonbr...@gmail.com>>> wrote:
    >>>
    >>> On 04/05/2019 11:43 AM, Michael R. Freedman wrote:
    >>>> Hello,
    >>>>
    >>>>
    >>>> If I remove the DSP from the equation by setting the DSP tuning
    >>>> policy to manual and assigning it to zero, I am coherent
    from tx to
    >>>> rx on all frequencies.  I'm now beginning to think that the
    DSP is
    >>>> doing it's tuning differently for tx and rx.  Or there is an
    >>>> accumulated error in opposite directions for both.  Thoughts?
    >>>>
    >>>>
    >>>> Leaving the DSP to zero is not a good solution however as
    there is
    >>>> too much LO leakage.
    >>>>
    >>>>
    >>> Could you try UHD 3.14.0.0?
    >>>
    >>> I think that you're using the -rc3 version at the moment.
    >>>
    >>>
    >>>> Mike
    >>>>
    >>>>
    >>>> On 03/27/2019 04:58 PM, Marcus D. Leech wrote:
    >>>>> On 03/27/2019 04:48 PM, Michael R. Freedman wrote:
    >>>>>> This is on a single UBX card within a single USRP.
    >>>>>>
    >>>>>>
    >>>>>> ./uhd_usrp_probe --args=addr=192.168.40.100
    >>>>>> [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
    >>>>>> UHD_3.14.0.0-0-unknown
    >>>>>> [INFO] [X300] X300 initialization sequence...
    >>>>>> [INFO] [X300] Maximum frame size: 8000 bytes.
    >>>>>> [INFO] [X300] Radio 1x clock: 200 MHz
    >>>>>> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
    >>>>>> 0xF1F0D00000000000)
    >>>>>> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1320 MB/s)
    >>>>>> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1294 MB/s)
    >>>>>> [INFO] [0/Radio_0] Initializing block control (NOC ID:
    >>>>>> 0x12AD100000000001)
    >>>>>> [INFO] [0/Radio_1] Initializing block control (NOC ID:
    >>>>>> 0x12AD100000000001)
    >>>>>> [INFO] [0/DDC_0] Initializing block control (NOC ID:
    >>>>>> 0xDDC0000000000000)
    >>>>>> [INFO] [0/DDC_1] Initializing block control (NOC ID:
    >>>>>> 0xDDC0000000000000)
    >>>>>> [INFO] [0/DUC_0] Initializing block control (NOC ID:
    >>>>>> 0xD0C0000000000000)
    >>>>>> [INFO] [0/DUC_1] Initializing block control (NOC ID:
    >>>>>> 0xD0C0000000000000)
    >>>>>> _____________________________________________________
    >>>>>>   /
    >>>>>> |       Device: X-Series Device
    >>>>>> | _____________________________________________________
    >>>>>> |    /
    >>>>>> |   |       Mboard: X310
    >>>>>> |   |   revision: 6
    >>>>>> |   |   product: 30410
    >>>>>> |   |   mac-addr0: 00:80:2f:0a:ff:98
    >>>>>> |   |   mac-addr1: 00:80:2f:0a:ff:99
    >>>>>> |   |   gateway: 192.168.10.1
    >>>>>> |   |   ip-addr0: 192.168.10.100
    >>>>>> |   |   subnet0: 255.255.255.0
    >>>>>> |   |   ip-addr1: 192.168.20.100
    >>>>>> |   |   subnet1: 255.255.255.0
    >>>>>> |   |   ip-addr2: 192.168.30.100
    >>>>>> |   |   subnet2: 255.255.255.0
    >>>>>> |   |   ip-addr3: 192.168.40.100
    >>>>>> |   |   subnet3: 255.255.255.0
    >>>>>> |   |   serial: F5BE45
    >>>>>> |   |   FW Version: 6.0
    >>>>>> |   |   FPGA Version: 35.1
    >>>>>> |   |   FPGA git hash: 4c165a5
    >>>>>> |   |   RFNoC capable: Yes
    >>>>>> |   |
    >>>>>> |   |   Time sources:  internal, external, gpsdo
    >>>>>> |   |   Clock sources: internal, external, gpsdo
    >>>>>> |   |   Sensors: ref_locked
    >>>>>> |   | _____________________________________________________
    >>>>>> |   |    /
    >>>>>> |   |   |       RX Dboard: A
    >>>>>> |   |   |   ID: UBX-40 v2 (0x007c)
    >>>>>> |   |   |   Serial: 313C181
    >>>>>> |   |   |
    _____________________________________________________
    >>>>>> |   |   |    /
    >>>>>> |   |   |   |       RX Frontend: 0
    >>>>>> |   |   |   |   Name: UBX RX
    >>>>>> |   |   |   |   Antennas: TX/RX, RX2, CAL
    >>>>>> |   |   |   |   Sensors: lo_locked
    >>>>>> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
    >>>>>> |   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
    >>>>>> |   |   |   |   Bandwidth range: 40000000.0 to 40000000.0 step
    >>>>>> 0.0 Hz
    >>>>>> |   |   |   |   Connection Type: IQ
    >>>>>> |   |   |   |   Uses LO offset: No
    >>>>>> |   |   |
    _____________________________________________________
    >>>>>> |   |   |    /
    >>>>>> |   |   |   |       RX Codec: A
    >>>>>> |   |   |   |   Name: ads62p48
    >>>>>> |   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
    >>>>>> |   | _____________________________________________________
    >>>>>> |   |    /
    >>>>>> |   |   |       RX Dboard: B
    >>>>>> |   |   |   ID: UBX-40 v2 (0x007c)
    >>>>>> |   |   |   Serial: 313C191
    >>>>>> |   |   |
    _____________________________________________________
    >>>>>> |   |   |    /
    >>>>>> |   |   |   |       RX Frontend: 0
    >>>>>> |   |   |   |   Name: UBX RX
    >>>>>> |   |   |   |   Antennas: TX/RX, RX2, CAL
    >>>>>> |   |   |   |   Sensors: lo_locked
    >>>>>> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
    >>>>>> |   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
    >>>>>> |   |   |   |   Bandwidth range: 40000000.0 to 40000000.0 step
    >>>>>> 0.0 Hz
    >>>>>> |   |   |   |   Connection Type: IQ
    >>>>>> |   |   |   |   Uses LO offset: No
    >>>>>> |   |   |
    _____________________________________________________
    >>>>>> |   |   |    /
    >>>>>> |   |   |   |       RX Codec: B
    >>>>>> |   |   |   |   Name: ads62p48
    >>>>>> |   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
    >>>>>> |   | _____________________________________________________
    >>>>>> |   |    /
    >>>>>> |   |   |       TX Dboard: A
    >>>>>> |   |   |   ID: UBX-40 v2 (0x007b)
    >>>>>> |   |   |   Serial: 313C181
    >>>>>> |   |   |
    _____________________________________________________
    >>>>>> |   |   |    /
    >>>>>> |   |   |   |       TX Frontend: 0
    >>>>>> |   |   |   |   Name: UBX TX
    >>>>>> |   |   |   |   Antennas: TX/RX, CAL
    >>>>>> |   |   |   |   Sensors: lo_locked
    >>>>>> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
    >>>>>> |   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
    >>>>>> |   |   |   |   Bandwidth range: 40000000.0 to 40000000.0 step
    >>>>>> 0.0 Hz
    >>>>>> |   |   |   |   Connection Type: QI
    >>>>>> |   |   |   |   Uses LO offset: No
    >>>>>> |   |   |
    _____________________________________________________
    >>>>>> |   |   |    /
    >>>>>> |   |   |   |       TX Codec: A
    >>>>>> |   |   |   |   Name: ad9146
    >>>>>> |   |   |   |   Gain Elements: None
    >>>>>> |   | _____________________________________________________
    >>>>>> |   |    /
    >>>>>> |   |   |       TX Dboard: B
    >>>>>> |   |   |   ID: UBX-40 v2 (0x007b)
    >>>>>> |   |   |   Serial: 313C191
    >>>>>> |   |   |
    _____________________________________________________
    >>>>>> |   |   |    /
    >>>>>> |   |   |   |       TX Frontend: 0
    >>>>>> |   |   |   |   Name: UBX TX
    >>>>>> |   |   |   |   Antennas: TX/RX, CAL
    >>>>>> |   |   |   |   Sensors: lo_locked
    >>>>>> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
    >>>>>> |   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
    >>>>>> |   |   |   |   Bandwidth range: 40000000.0 to 40000000.0 step
    >>>>>> 0.0 Hz
    >>>>>> |   |   |   |   Connection Type: QI
    >>>>>> |   |   |   |   Uses LO offset: No
    >>>>>> |   |   |
    _____________________________________________________
    >>>>>> |   |   |    /
    >>>>>> |   |   |   |       TX Codec: B
    >>>>>> |   |   |   |   Name: ad9146
    >>>>>> |   |   |   |   Gain Elements: None
    >>>>>> |   | _____________________________________________________
    >>>>>> |   |    /
    >>>>>> |   |   |       RFNoC blocks on this device:
    >>>>>> |   |   |
    >>>>>> |   |   |   * DmaFIFO_0
    >>>>>> |   |   |   * Radio_0
    >>>>>> |   |   |   * Radio_1
    >>>>>> |   |   |   * DDC_0
    >>>>>> |   |   |   * DDC_1
    >>>>>> |   |   |   * DUC_0
    >>>>>> |   |   |   * DUC_1
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>> Mike
    >>>>>>
    >>>>> OK, so could you use the tx_waveforms example in
    multi-channel mode
    >>>>> and confirm correct output on a spectrum analyser,
    >>>>>    or another X310 doing receive?
    >>>>>
    >>>>>
    >>>>>>
    >>>>>> On 03/27/2019 03:42 PM, Marcus D. Leech via USRP-users wrote:
    >>>>>>> On 03/27/2019 03:39 PM, Michael R. Freedman via
    USRP-users wrote:
    >>>>>>>> Marcus,
    >>>>>>>>
    >>>>>>>>
    >>>>>>>> I tried a 10MHz LOOffset with no change.  I also tried it at
    >>>>>>>> 1155.0MHz and 1160.0MHz. At 1155 the phase rolls... at
    1160 it
    >>>>>>>> does not.
    >>>>>>>>
    >>>>>>>>
    >>>>>>>> Mike
    >>>>>>>>
    >>>>>>> Could you give us a dump of uhd_usrp_probe for an X310 that
    >>>>>>> displays this issue?  What version of UHD?   Also, to be
    clear,
    >>>>>>> this is within
    >>>>>>>    a *single* X310, correct?
    >>>>>>>
    >>>>>>>
    >>>>>>>> On 03/27/2019 11:10 AM, Marcus D. Leech via USRP-users
    wrote:
    >>>>>>>>> On 03/27/2019 10:41 AM, Michael R. Freedman via
    USRP-users wrote:
    >>>>>>>>>> Any thoughts on this?
    >>>>>>>>>>
    >>>>>>>>>>
    >>>>>>>>>> Mike
    >>>>>>>>>>
    >>>>>>>>> Given that in this case, the incoming carrier will be
    fighting
    >>>>>>>>> DC-offset removal rather hard, I wonder if this is a weird
    >>>>>>>>> artifact of DC-offset
    >>>>>>>>>    removal?
    >>>>>>>>>
    >>>>>>>>> If you use offset tuning on the RX, do you still see a
    >>>>>>>>> significant phase roll?
    >>>>>>>>>
    >>>>>>>>>
    >>>>>>>>>> On 03/25/2019 01:04 PM, Michael R. Freedman via USRP-users
    >>>>>>>>>> wrote:
    >>>>>>>>>>> Marcus,
    >>>>>>>>>>>
    >>>>>>>>>>>     190Hz is what we calculated.  I have attached a
    text file
    >>>>>>>>>>> with the data we used.  This is a single UBX40 tuned
    to 155MHz
    >>>>>>>>>>> sampling at 2MHz.
    >>>>>>>>>>>
    >>>>>>>>>>>
    >>>>>>>>>>> Mike
    >>>>>>>>>>>
    >>>>>>>>>>>
    >>>>>>>>>>> On 03/25/2019 12:34 PM, Nick Foster wrote:
    >>>>>>>>>>>> Well, according to your description, you could
    transmit a
    >>>>>>>>>>>> carrier from TX to RX (through an attenuator) with
    both sides
    >>>>>>>>>>>> set to the same frequency. Your received signal
    should look
    >>>>>>>>>>>> like a sine wave at the frequency of the offset.
    >>>>>>>>>>>>
    >>>>>>>>>>>> On Mon, Mar 25, 2019 at 9:16 AM Michael R. Freedman via
    >>>>>>>>>>>> USRP-users <usrp-users@lists.ettus.com
    <mailto:usrp-users@lists.ettus.com>
    >>>>>>>>>>>> <mailto:usrp-users@lists.ettus.com
    <mailto:usrp-users@lists.ettus.com>>> wrote:
    >>>>>>>>>>>>
    >>>>>>>>>>>>      Hello,
    >>>>>>>>>>>>
    >>>>>>>>>>>>      Do you have any suggestions as to how to
    measure the
    >>>>>>>>>>>> frequency delta between the transmit channel and the
    >>>>>>>>>>>> receive channel?
    >>>>>>>>>>>>
    >>>>>>>>>>>>      As I sat down to do this, I realized I have no
    real way
    >>>>>>>>>>>>      to do that.
    >>>>>>>>>>>>
    >>>>>>>>>>>>
    >>>>>>>>>>>>      Mike
    >>>>>>>>>>>>
    >>>>>>>>>>>>
    >>>>>>>>>>>>
    >>>>>>>>>>>>
    >>>>>>>>>>>>
    >>>>>>>>>>>>      On 03/24/2019 03:23 PM, Marcus D. Leech via
    USRP-users
    >>>>>>>>>>>> wrote:
    >>>>>>>>>>>>>      On 03/24/2019 02:39 PM, Freedman, Michael -
    1008 - MITLL
    >>>>>>>>>>>>> via USRP-users wrote:
    >>>>>>>>>>>>>>      It is not just a phase offset. It is a frequency
    >>>>>>>>>>>>>> offset. The phase drifts between the two. I can
    tolerate
    >>>>>>>>>>>>>> a phase offset at startup. A freq offset however is
    >>>>>>>>>>>>>> causing problems.
    >>>>>>>>>>>>>>
    >>>>>>>>>>>>>>      Mike
    >>>>>>>>>>>>>>
    >>>>>>>>>>>>>>      Sent from my iPhone
    >>>>>>>>>>>>>>
    >>>>>>>>>>>>>>      On Mar 24, 2019, at 4:28 AM, Marcus Müller
    >>>>>>>>>>>>>> <marcus.muel...@ettus.com
    <mailto:marcus.muel...@ettus.com>>
    >>>>>>>>>>>>>> <mailto:marcus.muel...@ettus.com
    <mailto:marcus.muel...@ettus.com>> wrote:
    >>>>>>>>>>>>>>
    >>>>>>>>>>>>>>      Can you elaborate on what "not coherent" means to
    >>>>>>>>>>>>>> you – the relative
    >>>>>>>>>>>>>>      phase should be constant after each tune, but
    if you
    >>>>>>>>>>>>>> don't tune
    >>>>>>>>>>>>>>      simultaneously, i.e. with timed commands,
    random at
    >>>>>>>>>>>>>> each tune.
    >>>>>>>>>>>>>>
    >>>>>>>>>>>>>>      Best regards,
    >>>>>>>>>>>>>>      Marcus
    >>>>>>>>>>>>> Also, what version of UHD?  What hardware rev of UBX
    >>>>>>>>>>>>> cards?
    >>>>>>>>>>>>>
    >>>>>>>>>>>>>
    >>>>>>>>>>>>>>      On Sat, 2019-03-23 at 17:06 -0400, Michael R.
    >>>>>>>>>>>>>> Freedman via USRP-users
    >>>>>>>>>>>>>>      wrote:
    >>>>>>>>>>>>>>>      Hello,
    >>>>>>>>>>>>>>>
    >>>>>>>>>>>>>>>
    >>>>>>>>>>>>>>>      I have an issue where I tune both the TX and RX
    >>>>>>>>>>>>>>> side of a UBX40 card
    >>>>>>>>>>>>>>>      in
    >>>>>>>>>>>>>>>      an X310 to the same frequency and find that the
    >>>>>>>>>>>>>>> transmitted signal
    >>>>>>>>>>>>>>>      and
    >>>>>>>>>>>>>>>      what is received are not coherent.  I am
    using an
    >>>>>>>>>>>>>>> external 10MHz
    >>>>>>>>>>>>>>>      reference and have tried the documented
    suggestions.
    >>>>>>>>>>>>>>>
    >>>>>>>>>>>>>>>      at 150MHz it is coherent.
    >>>>>>>>>>>>>>>
    >>>>>>>>>>>>>>>      at 155MHz it is NOT coherent.
    >>>>>>>>>>>>>>>
    >>>>>>>>>>>>>>>
    >>>>>>>>>>>>>>>      I have tried setting the dboard_clock_rate to
    >>>>>>>>>>>>>>> 20MHz.  This made the
    >>>>>>>>>>>>>>>      problem appear at 150MHz as well.  I've tried
    >>>>>>>>>>>>>>> integer_n tuning.
    >>>>>>>>>>>>>>>
    >>>>>>>>>>>>>>>      I have verified that the ref_lock and
    lo_lock are
    >>>>>>>>>>>>>>> both true.
    >>>>>>>>>>>>>>>
    >>>>>>>>>>>>>>>
    >>>>>>>>>>>>>>>      Any suggestions?
    >>>>>>>>>>>>>>>
    >>>>>>>>>>>>>>>
    >>>>>>>>>>>>>>>      Mike
    >>>>>>>>>>>>>>>
    >>>>>>>>>>>>>>>
    >>>>>>>>>>>>>>>      _______________________________________________
    >>>>>>>>>>>>>>>      USRP-users mailing list
    >>>>>>>>>>>>>>> USRP-users@lists.ettus.com
    <mailto:USRP-users@lists.ettus.com>
    >>>>>>>>>>>>>>> <mailto:USRP-users@lists.ettus.com
    <mailto:USRP-users@lists.ettus.com>>
    >>>>>>>>>>>>>>>
    >>>>>>>>>>>>>>>
    http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
    >>>>>>>>>>>>>>>
    >>>>>>>>>>>>>>
    >>>>>>>>>>>>>>      _______________________________________________
    >>>>>>>>>>>>>>      USRP-users mailing list
    >>>>>>>>>>>>>> USRP-users@lists.ettus.com
    <mailto:USRP-users@lists.ettus.com>
    >>>>>>>>>>>>>> <mailto:USRP-users@lists.ettus.com
    <mailto:USRP-users@lists.ettus.com>>
    >>>>>>>>>>>>>>
    >>>>>>>>>>>>>>
    http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
    >>>>>>>>>>>>>>
    >>>>>>>>>>>>>
    >>>>>>>>>>>>>
    >>>>>>>>>>>>> _______________________________________________
    >>>>>>>>>>>>> USRP-users mailing list
    >>>>>>>>>>>>> USRP-users@lists.ettus.com
    <mailto:USRP-users@lists.ettus.com>
    >>>>>>>>>>>>> <mailto:USRP-users@lists.ettus.com
    <mailto:USRP-users@lists.ettus.com>>
    >>>>>>>>>>>>>
    >>>>>>>>>>>>>
    http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
    >>>>>>>>>>>>>
    >>>>>>>>>>>> _______________________________________________
    >>>>>>>>>>>> USRP-users mailing list
    >>>>>>>>>>>> USRP-users@lists.ettus.com
    <mailto:USRP-users@lists.ettus.com>
    >>>>>>>>>>>> <mailto:USRP-users@lists.ettus.com
    <mailto:USRP-users@lists.ettus.com>>
    >>>>>>>>>>>>
    >>>>>>>>>>>>
    http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
    >>>>>>>>>>>>
    >>>>>>>>>>>>
    >>>>>>>>>>>
    >>>>>>>>>>>
    >>>>>>>>>>> _______________________________________________
    >>>>>>>>>>> USRP-users mailing list
    >>>>>>>>>>> USRP-users@lists.ettus.com
    <mailto:USRP-users@lists.ettus.com>
    >>>>>>>>>>>
    http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
    >>>>>>>>>>>
    >>>>>>>>>>
    >>>>>>>>>>

    _______________________________________________
    USRP-users mailing list
    USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
    http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Reply via email to