We’re in the same boat there for sure! Yeah, I saw there was some pretty bold things happening in there (rounding and such). I had wondered about sending a 2-D array.
I will try to do more with the Python next week. Good news is, At the moment i have observed only a very small amount of instantaneous phase error over a short amount of time. Which reflects the graphs in the N321 docs. Obviously that doesn’t count for temperature fluctuation or extended runtime effects, but it’s a start! Thanks for the help. <end transmission> > On Jan 21, 2022, at 17:17, Marcus D. Leech <[email protected]> wrote: > > > On 2022-01-21 16:52, Paul Atreides wrote: >> ok. is that just setting up 2 streamers to start at the same time? >> > From looking at the code, I *THINK* that if you send it a 2D numpy array the > rows represent the channels. > > The "send_waveform" API is Python-API only, and does a fair amount of > dancing-around to "make things just work" > even if you only send a 1D wave-form array. > > But, of course, I cannot find any documentation on it, just looking at the > code. > > >> On Fri, Jan 21, 2022 at 4:50 PM Marcus D. Leech <[email protected]> >> wrote: >>> On 2022-01-21 16:46, Paul Atreides wrote: >>>> is there a way to incur a phase shift on one of the streams from the >>>> in-built UHD examples? >>>> the python API allows has >>>> >>>> usrp.send_waveform(samples, duration, center_freq, sample_rate, >>>> [0,1],gain) >>>> >>>> but this sends the same samples to both outputs. I've used this icommand >>>> in conjunction with the LO sharing options for the multi_usrp object to >>>> confirm the phase between channels >>>> i'd like to be able to apply some digital phase shift between the 2 to >>>> test the level of control, hence all the gr-uhd questions. >>>> >>>> any ideas or references? >>> You'll probably have to send samples yourself, with phase-offsets between >>> the two sample streams. >>> >>> >>>> >>>> On Wed, Jan 19, 2022 at 9:41 AM Rob Kossler <[email protected]> wrote: >>>>> On Wed, Jan 19, 2022 at 1:00 AM Paul Atreides <[email protected]> >>>>> wrote: >>>>> > >>>>> > Ok, so just circling back on this. Ive got a decent handle on the >>>>> > Python API. I’ve confirmed the LO signal comes out of the port once the >>>>> > splitter output is enabled. >>>>> > >>>>> > Rob you’re saying that for sure both channels need to be external AND >>>>> > exported? making the settings: >>>>> > TX 0: >>>>> > LO source = external >>>>> > LO Exported = true >>>>> > TX 1: >>>>> > LO source = external >>>>> > LO Exported = true >>>>> Yes, except as you pointed out below, LO Exported for Tx1 is not >>>>> needed and likely does nothing. >>>>> >>>>> > >>>>> > Radio #0 TX LO OUT 0 = enabled >>>>> > Radio #1 TX LO OUT 1 = enabled (for debug) >>>>> > (When I set These they turn on the lights for the LO outs) >>>>> > >>>>> > The front panel cable should connect TX LO output 0 to TX LO Input 1 >>>>> Yes >>>>> >>>>> > >>>>> > Like you said, According to the block diagram, the TX LO input 1 should >>>>> > connect both channels to the 1x2 splitter so I should only need 1 LO >>>>> > output turned on. Id like to point out that in the block diagram it >>>>> > also doesn’t look like it’s possible to export channel 1’s LO. The only >>>>> > connection in the diagram is internal. >>>>> >>>>> Yes, Somewhere in the Ettus documentation, it indicates that this is >>>>> the case (I've forgotten where). >>>>> >>>>> > >>>>> > Am I missing something? Have you gotten this to work? >>>>> Yes, I have been using this in a 16x16 system with 8 N321 devices all >>>>> connected by a single LO (arbitrarily chosen LO export channel >>>>> distributed to both Tx and Rx LO inputs). I've also tested it on >>>>> smaller systems as small as 4x4 (and possibly 2x2 like your case, but >>>>> not positive on this). >>> >
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
