Closed jaycedowell closed 1 year ago
Looking at what BeamformerOp
writes to its output ring it looks like there is a beam numbering problem somewhere. A beam command for beam 1 is translated to beam 0 (somewhere) and the beam comes out in the wrong place. Is this in the control software?
Is this in the control software?
Yes - https://github.com/lwa-project/ng_digital_processor/blob/sevilleta_based/scripts/ndp/Ndp.py#L227
This also seems to happen with DRX commands but they have zero-based beam indexing to start with. Maybe the correct thing to do is update ndp_drx.py
so that it expects zero-based beam indexing?
After c7ba513 it looks like we still have zeros, now at the output of ReChannelizerOp
.
This problem with ReChannelizerOp
could be related to a seg fault I get when I try to bifrost.memory.memset
the internal data buffer to zero. I had commented that out at some point but maybe that needs to be solved first.
Replaced the bifrost.memory.memset
call with a bifrost.ndarray.memset_array
call. That helps but does point out a problem with how bifrost.memory.memset
in implemented. It seems to rely on ndarray.flags
for space information that isn't there.
Tracked this down to a bifrost.fft
problem that I hadn't completely patched (see https://github.com/ledatelescope/bifrost/issues/202). Now non-zero data comes out of the T-engine at least for the non-PFB inverter case. I'll keep this open until I test with the inverter turned on.
The inverter doesn't appear to be inverting correctly but the data are non-zero.
Everything is zero coming into
ReChannelizerOp
. Capture looks ok-ish at ~5% packet loss. Zeros in is zeros out.