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