Hello Brian, Thank you for the additional information.
Regarding #6, I meant that if you have two TwinRX daughterboards, see if you get this problem when the fixed channel is on one daughterboard, and the tuned channel is on the other. Regarding screenshots, are you referring to any particular frequency and time region, or is everything above the noise floor associated with the tuning? In other words, is the clean spectrum where there is nothing above the noise floor in both time and frequency plots? Also can you explain what you mean by "shows some analog PLL-style locking for around 10 ms of time, then goes away"? Are you referring to the burst from 3 ms to 13 ms, or something specifically at 10 ms? Lastly, what are your spectrogram parameters to generate the waterfall? I'll reach out again after I attempt to reproduce. Regards, Wan On Tue, Oct 25, 2022 at 8:29 PM Brian Padalino <bpadal...@gmail.com> wrote: > Hey Wan, > > Thanks for the quick response. > > On Tue, Oct 25, 2022 at 7:59 PM Wan Liu <wan....@ettus.com> wrote: > >> Hello Brian, >> >> I'll see if I can reproduce with my TwinRX. Please provide some more >> information to help me reproduce... >> >> 1. Center Frequency of fixed channel 0 >> > > I tested at 915 MHz, but also 400 MHz. It seems to show up wherever I > happen to tune the fixed channel. > > >> 2. Tuning range on channel 1 >> > > I have tried with just 2 frequencies (200 MHz, 500 MHz) or the full > frequency range. Tuning the full frequency range seems to provide more > noise in different areas of the spectrum. > > >> 3. What tuning rate have you tried and what's the threshold between a >> clean spectrum and a bad one? >> > > I always get bad spectrum regardless of my dwell time on any particular > frequency. The "max hold" will always show approximately the same spectral > image. The "average" spectrum will obviously be quieter if I dwell for > longer. > > >> 4. Please share screenshots of what you are seeing >> > > Attached is a 10 ms capture of what I see often. It's only one particular > case, but you can see what is going on. I have included time vs. freq, > amplitude vs. freq, and amplitude vs. time plots. > > >> 5. Please share uhd_usrp_probe output so I know your serial, revision, >> uhd version, etc >> > > Attached as uhd_probe.txt. > > >> 6. Can you reproduce this problem when it's two channels on different >> daughterboards? In other words, ch 0 and ch 1 on the same TwinRX, and ch 0 >> and ch 1 across each DB slot. >> > > I am unsure exactly what you're asking for here. My current setup has a > UBX in DB0 and a TwinRX in DB1. If you can be more specific about what you > want me to try, I can give it a shot? > > I will note 2 more observations I made: > > - When trying to read the lo_locked sensor continuously, generating SPI > traffic I presume going to the PLLs, I get clean spectrum. This suggests > to me that digital noise isn't the culprit here. > - The IQ file I saved and looked at (which generated the attached > figures) shows some analog PLL-style locking for around 10 ms of time, then > goes away. > > >> >> There's several switchable routes before and after each stage LO going >> across channels, so it's possible there are some isolation problems between >> channels. My first thought is also to remove LO sharing cables, but as you >> said, it doesn't improve. >> >> Maybe switching the switches that are not used might help give better >> isolation. From schematic, if channel 1 uses its own LO, then only switch >> 16 is needed, and switch 14 which routes LO 1 to the sister channel 2 isn't >> used. So I'm wondering if the state of switch 14 makes a difference in >> terms of isolation. I'd have to check the software to see if you can >> independently flip these switches, and if it's recommended, to test this >> hypothesis. I will also check internally if similar issue is reported and >> get back to you. >> > > Let me know if there's anything else I can provide to try to help out. I > have a very long IQ capture I took (both inputs terminated, recording fixed > channel while retuning the other channel) but it's obviously too big to > share here. > > Thanks, > Brian >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
