Hi Jason, Thanks for looking into this.
Do you know what it is about the case of 8 ants and demux = 8 that brings about this anomaly? By which I mean, are there other combinations which you would also expect to behave this way? Cheers, Jack On 20 October 2010 09:25, Jason Manley <[email protected]> wrote: > It looks like things are working as they should, but that's not to say that > they're working the way we expect. > > In your case of 8 antennas with demux of 8, output group number 31 is > actually baseline 5_0 (which is what the x engines produce natively). But > this is not what is normally expected so I conjugate the output and relabel > it (0,5). It seems this scheme is a little too simple though... you get > 0x5x,0y5y,0y5x,0x5y instead of what we expect (0x5x,0y5y,0x5y,0y5x). This is > true for the entire last output triangle (baselines 0_5,0_6,0_7,1_6,1_7,2_7 > for the 8antenna case). > > For each one, you first get the real component and then the imaginary > component. So that non-zero value corresponds to 0y5x real, which is as > expected for your input. > > Maybe I should build-in a little reorder block or change the descramble to > read out in the expected order. I'll think about this a little more. Thanks > for bringing it to my attention. > > Jason > > On 19 Oct 2010, at 22:37, Jack Hickish wrote: > > > Hi All, > > > > After some bizarre cross-pol results in a recent observing run, I started > taking a semi-careful look at the order the X-engine outputs data. As far as > I can tell, the output order of the x-engine doesn't quite match the order > expected by the casper recieving code... > > > > -- The order according to software (corr 0.5, though 0.4.2 gives the same > result). > > Running corr.sim.get_bl_order(8) returns: > > In [7]: corr.sim.get_bl_order(8) > > Out[7]: > > ((0, 0), > > (0, 1), > > (1, 1), > > (0, 2), > > (1, 2), > > (2, 2), > > (0, 3), > > (1, 3), > > (2, 3), > > (3, 3), > > (0, 4), > > (1, 4), > > (2, 4), > > (3, 4), > > (4, 4), > > (1, 5), > > (2, 5), > > (3, 5), > > (4, 5), > > (5, 5), > > (2, 6), > > (3, 6), > > (4, 6), > > (5, 6), > > (6, 6), > > (3, 7), > > (4, 7), > > (5, 7), > > (6, 7), > > (7, 7), > > (0, 5), > > (0, 6), > > (0, 7), > > (1, 6), > > (1, 7), > > (2, 7)) > > > > Judging by the behaviour of casper receive code and bit of documentation > floating around, I also expect the output of each baseline to contain > (consecutively) values for the XX, YY, XY and YX polarisations, in that > order. > > > > -- The order according to simulink > > I knocked up a simple model (using a new clone of mlib_devel i grabbed > about an hour ago), that feeds an X-Engine block with the following signals: > > 0x = 1x = 2x = 3x = 4x = 5x = 6x = 7x = 2 > > 0y = 1 > > All other y-pols = 0 > > > > I attach a plot of the output of the x-engine (rescaled to remove the > accumulation in the xeng block) > > > > Essentially, all is well apart from the (0,5),(0,6),(0,7) outputs, which, > if you believe the software order, show signals in 0x5y, 0x6y, and 0x7y, > rather than 0y5x, 0y6x and 0y7x. > > > > So my question is, am I using the x-engine block incorrectly, or is this > a real bug? I'm sure it's easy to fix (I haven't yet checked, but at a guess > I'd say the baselines from 0,5 - 2,7 (so called 'order2' in the get_bl_order > script) are backwards), but I thought before I go changing bits of code I'd > check that I wasn't about to mess with something that isn't broken. > > > > Thanks, > > > > Jack > > > > > > > > > > <Screenshot-1.png> > >
