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>
