Hey Marcus,
I checked and the cal files are in the correct location. I was using a gain of
10, but even at 0 I can start to see the lo peak out of the noise floor. In
rfnoc:radio_control I did see a set_tx_dc_offset() but Im not sure how to read
the cal file to get the value manually or how to pass it the file.
I am now trying to find a way to offset tune the lo but can't figure out how to
do that with rfnoc. I tried uhd::rfnoc::radio_control set_tx_freq with a
tune_request_t but that didn't work, my guess is that is for the multiusrp and
not rfnoc radio control. I saw there was a set_tx_lo_freq but it expects 3
arguments one being name of lo stage which I haven't been able to decipher. So
far I have only found examples without rfnoc using usrp::multiusrp.
________________________________
From: usrp-users-requ...@lists.ettus.com <usrp-users-requ...@lists.ettus.com>
Sent: Tuesday, September 27, 2022 8:19 PM
To: usrp-users@lists.ettus.com <usrp-users@lists.ettus.com>
Subject: USRP-users Digest, Vol 145, Issue 60
Send USRP-users mailing list submissions to
usrp-users@lists.ettus.com
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
usrp-users-requ...@lists.ettus.com
You can reach the person managing the list at
usrp-users-ow...@lists.ettus.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: USRP-users Digest, Vol 145, Issue 55 (Marcus D. Leech)
2. Re: Reset Timing Violation (Brian Padalino)
3. Re: Reset Timing Violation (Wade Fife)
----------------------------------------------------------------------
Message: 1
Date: Tue, 27 Sep 2022 09:44:08 -0400
From: "Marcus D. Leech" <patchvonbr...@gmail.com>
Subject: [USRP-users] Re: USRP-users Digest, Vol 145, Issue 55
To: usrp-users@lists.ettus.com
Message-ID: <e32a7073-710a-1279-fbe9-ce50f3a80...@gmail.com>
Content-Type: multipart/alternative;
boundary="------------gvkvlFFcHe0JJA1MHesKFzhB"
On 2022-09-27 09:01, Avila, Jose A wrote:
> Using the UBX board on the x310 and the lo leakage is the same
> amplitude if not higher than the signal being played with rfnoc
> samples from file.
>
Can you confirm that it placed .cal files in the appropriate directory:
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffiles.ettus.com%2Fmanual%2Fpage_calibration.html%23calibration_data&data=05%7C01%7Cjaavila5%40miners.utep.edu%7C831033990cc2406a426608daa0f7ee6f%7C857c21d21a1643a490cfd57f3fab9d2f%7C1%7C0%7C637999283960023866%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2uxlWwt7G3rjdaWH0ZK5fbvneyRBlOyodbnar7rn7Tk%3D&reserved=0
What gain setting are you using when transmitting?
>
> ------------------------------------------------------------------------
> *From:* usrp-users-requ...@lists.ettus.com
> <usrp-users-requ...@lists.ettus.com>
> *Sent:* Saturday, September 24, 2022 3:31:13 AM
> *To:* usrp-users@lists.ettus.com <usrp-users@lists.ettus.com>
> *Subject:* USRP-users Digest, Vol 145, Issue 55
> Send USRP-users mailing list submissions to
> usrp-users@lists.ettus.com
>
> To subscribe or unsubscribe via email, send a message with subject or
> body 'help' to
> usrp-users-requ...@lists.ettus.com
>
> You can reach the person managing the list at
> usrp-users-ow...@lists.ettus.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of USRP-users digest..."
>
> Today's Topics:
>
> 1. X310 calibration (Avila, Jose A)
> 2. Re: X310 calibration (Marcus D. Leech)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 23 Sep 2022 17:36:37 +0000
> From: "Avila, Jose A" <jaavi...@miners.utep.edu>
> Subject: [USRP-users] X310 calibration
> To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
> Message-ID: <SN4PR0501MB391923D92DB5B6B7A2F84EE5D9519@SN4PR0501MB3919
> .namprd05.prod.outlook.com>
> Content-Type: multipart/alternative; boundary="_000_SN4PR0501MB3919
> 23D92DB5B6B7A2F84EE5D9519SN4PR0501MB3919_"
>
> I have noticeable lo leakage when running the cpp rfnoc replay samples
> from file. So I ran the calibration functions but it doesn't seem to
> be using the created files since I did not notice a difference. Is
> there a function call or setting in cpp I need to add? I thought it
> would be automatic. Using uhd 4.2 with X310.
> -------------- next part --------------
> A message part incompatible with plain text digests has been removed ...
> Name: not available
> Type: text/html
> Size: 477 bytes
> Desc: not available
>
> ------------------------------
>
> Message: 2
> Date: Fri, 23 Sep 2022 14:16:48 -0400
> From: "Marcus D. Leech" <patchvonbr...@gmail.com>
> Subject: [USRP-users] Re: X310 calibration
> To: usrp-users@lists.ettus.com
> Message-ID: <fc5fc6fa-d33f-9958-7e58-2fe637175...@gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 2022-09-23 13:36, Avila, Jose A wrote:
> > I have noticeable lo leakage when running the cpp rfnoc replay samples
> > from file. So I ran the calibration functions but it doesn't seem to
> > be using the created files since I did not notice a difference. Is
> > there a function call or setting in cpp I need to add? I thought it
> > would be automatic. Using uhd 4.2 with X310.
> >
> Which daughtercards are you using?
>
> I'll note that most of the DC-offset compensation is done in a
> daughtercard-independent way and doesn't rely on the
> CAL functions as far as I know--there's a continuous "DC offset
> removal" function in the FPGA.
>
> When you say "noticeable" what is the magnitude we're talking about?
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
>
> ------------------------------
>
> End of USRP-users Digest, Vol 145, Issue 55
> *******************************************
>
> _______________________________________________
> USRP-users mailing list --usrp-users@lists.ettus.com
> To unsubscribe send an email tousrp-users-le...@lists.ettus.com
-------------- next part --------------
A message part incompatible with plain text digests has been removed ...
Name: not available
Type: text/html
Size: 8740 bytes
Desc: not available
------------------------------
Message: 2
Date: Tue, 27 Sep 2022 10:08:48 -0400
From: Brian Padalino <bpadal...@gmail.com>
Subject: [USRP-users] Re: Reset Timing Violation
To: adri96r...@gmail.com
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Message-ID:
<CAEXYVK7f-nyQXPDo6WkVm3SCYM2EvzNVuDeQ4+k-7wqc7Oa=b...@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="000000000000881e7405e9a92fba"
On Tue, Sep 27, 2022 at 7:21 AM <adri96r...@gmail.com> wrote:
> Hi every one!
>
>
> I am facing some problems with reset timing violations. This is is one for
> example, and i have a fews. I tried to instantiate the reset signal but it
> didn work. I don know how to fix it. On the other side, i have seen a reset
> generation in a noc shell and i was wondering if i have to generate a new
> one from a previous one.
>
I can't see much other than the names of the signals and the negative
slack, but the hierarchy seems to indicate it's part of a synchronizer
that's been double flopped, so maybe there should be a false path
associated with it in your constraints?
Brian
-------------- next part --------------
A message part incompatible with plain text digests has been removed ...
Name: not available
Type: text/html
Size: 983 bytes
Desc: not available
------------------------------
Message: 3
Date: Tue, 27 Sep 2022 21:19:19 -0500
From: Wade Fife <wade.f...@ettus.com>
Subject: [USRP-users] Re: Reset Timing Violation
To: Brian Padalino <bpadal...@gmail.com>
Cc: adri96r...@gmail.com, "USRP-users@lists.ettus.com"
<usrp-users@lists.ettus.com>
Message-ID:
<CAFche=hvgtfh8+thzt23p1ddrm+3mrinx2w-jywgc1tahjy...@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="000000000000624bcd05e9b36488"
There's not enough information in the screen shot, but I think the output
of the double synchronizer is on a different clock domain than flop flop
(dato_entrada) being reset by it.
The reset signal needs to be driven by the same clock as the flip flop
being reset, otherwise Vivado can't ensure that the requirements of the FF
will be met, resulting in this timing violation.
Make sure you're using the right clock and reset signal for your
dato_entrada register.
Wade
On Tue, Sep 27, 2022 at 9:10 AM Brian Padalino <bpadal...@gmail.com> wrote:
> On Tue, Sep 27, 2022 at 7:21 AM <adri96r...@gmail.com> wrote:
>
>> Hi every one!
>>
>>
>> I am facing some problems with reset timing violations. This is is one
>> for example, and i have a fews. I tried to instantiate the reset signal but
>> it didn work. I don know how to fix it. On the other side, i have seen a
>> reset generation in a noc shell and i was wondering if i have to generate a
>> new one from a previous one.
>>
> I can't see much other than the names of the signals and the negative
> slack, but the hierarchy seems to indicate it's part of a synchronizer
> that's been double flopped, so maybe there should be a false path
> associated with it in your constraints?
>
> Brian
> _______________________________________________
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
-------------- next part --------------
A message part incompatible with plain text digests has been removed ...
Name: not available
Type: text/html
Size: 2247 bytes
Desc: not available
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 145, Issue 60
*******************************************
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
