Hi Nick, I can try this, but the reason I disable one or the other streamer is so that I can sample at the full 50MHz. Running both streamers cuts the sample rate in half and I am only using the cal channel to measure/correct the random LO phase offset.
In this switching mode, the data always comes from radio block 1, but the AD9361 routes it to either RXA or RXB at full rate depending on the active streamer. I also switch back and forth between the channels thousands of times on a single power cycle without an issue. Even if I only receive on a single channel (RXA) and match filter with a reference waveform file, I am still seeing the same behavior: tight groupings in measured phase slope delay but with random hops in group mean whenever the image is reloaded. Sam On Mar 9, 2018, 10:22 AM -0800, Nick Foster <[email protected]>, wrote: > One thing that struck me: I don't think you should have to disable the > streamer to switch between cal and radio channels. Just for experiment's > sake, try leaving both channels active in the streamer. You can pull samples > from both channels in your recv() command, and just use the channel you're > interested in. Does doing this affect the result? > > Nick > > > On Fri, Mar 9, 2018 at 10:13 AM Samuel Prager <[email protected]> wrote: > > > Hey Nick, > > > > > > No prob blew at all. The flag “no_reload_fpga” seems to work for that. > > > The bigger problem is that each time the fpga image is loaded on the > > > e3xx, the relative path delays between the RXA and RXB channels changes > > > randomly as seen by the sample group jumps in the image I originally > > > attached. The random LO phase is measured and removed, so there is > > > something else happening in this strange case. > > > > > > If anyone has any ideas as to what could be causing this please help! The > > > phase stability of the E312 is amazing within the same fpga image cycle > > > but these relatively large jumps after reload/ power cycle are a deal > > > breaker for some applications! > > > > > > Thanks > > > > > > Sam > > > > > > On Mar 9, 2018, 9:19 AM -0800, Nick Foster via USRP-users > > > <[email protected]>, wrote: > > > > Sam, > > > > > > > > Sorry I haven't gotten back -- it sounds like you're doing everything > > > > right. The usual quick fixes probably don't apply here. I haven't had > > > > time to look more in depth into it, or to try to replicate it on my own > > > > hardware. > > > > > > > > Marcus is right -- the E3xx uses an idle image in order to reduce power > > > > consumption when the radio is inactive. I'm not sure if there's a flag > > > > that will tell UHD not to load the idle image. > > > > > > > > Nick > > > > > > > > > On Thu, Mar 8, 2018 at 9:30 PM Marcus D. Leech via USRP-users > > > > > <[email protected]> wrote: > > > > > > On 03/09/2018 12:11 AM, Samuel Prager via USRP-users wrote: > > > > > > > Still looking for more info on this problem. > > > > > > > > > > > > > > I have the exact same RfNoC block/software program running on an > > > > > > > X300 and see no such jumps or otherwise unexpected behavior. > > > > > > > > > > > > > > I have attempted to isolate this issue on the E312 by creating > > > > > > > the device3 with the “no_reload_fpga” flag. (Appropriate image is > > > > > > > loaded before hand with the uhd_usrp_image_loader. Running my > > > > > > > program the first time works as expected, but if I kill the > > > > > > > program and restart, I get this error: > > > > > > > > > > > > > > “AssertionError: zf_peek32(ctrl_base+ARBITER_RB_ADDR_SPACE) > 0 > > > > > > > in virtual void e300_fifo_mb::release()" > > > > > > > > > > > > > > The last few lines in the Uhd log file are: > > > > > > > > > > > > > > > > > > > > > e300_impl.cpp:639,1,E300,[E300] Setting up dest map for host ep 0 > > > > > > > to be stream 0 > > > > > > > > > > > > > > device3_impl.cpp:131,0, DEVICE3, Setting up NoC-Shell Control for > > > > > > > port #0 (SID; 00:00>02:10) > > > > > > > device3_impl.cpp:139,0,DEVICE3, OK > > > > > > > davice3_impl.cpp:141,0, DEVICE3, Port 16: found NoC-Block with ID > > > > > > > 12AD100000000000. > > > > > > > e300_impl.cpp:639,1,E300, [E300] Setting up dest map for host ep > > > > > > > 1 to be stream 1 > > > > > > > > > > > > > > device3_impl.cpp:160,0,DEVICE3, Setting up NoC Shell port for #1 > > > > > > > (SID: 00:01>02:11) > > > > > > > > > > > > > > > > > > > > > > > > > > > > Shouldn’t the E312 be able to operate without needing to reload > > > > > > > the FPGA image each time? Has this been tested? I would really > > > > > > > appreciate any hints or pointers into why this is happening. > > > > > > > > > > > > > > Thank you, > > > > > > > > > > > > > > Sam > > > > > > > > > > > > > The E3xx run an "idle" image when the device is not being used. I > > > > > > cannot remember the reason for that, TBH. > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > USRP-users mailing list > > > > > > [email protected] > > > > > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > > _______________________________________________ > > > > USRP-users mailing list > > > > [email protected] > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com&d=DwICAg&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=opIuWAKmywF059tAs2i3Pg&m=HkJbIenCP1t5oGgIxFFvHftFEabvbCk9VlUuv6EBHqA&s=HutNULVtirv0JuQ4R8HiR34nBs82dDVsc3zQccm3BTU&e=
_______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
