No, it is like this for all cases. I've attached a spreadsheet showing the native output order for a 16 antenna X engine during a single window. Readouts happen from right to left, line by line. The green cells are the only ones that the green xeng block actually outputs because there is a descramble block inside there that removes the duplicated "red" baselines. A conj_fix block corrects the conjugation problems in the bottom triangle (though, apparently not perfectly!).
I think I've come up with a simple fix to this problem. It will amount to moving the conj fix block in front of the descramble block. Unfortunately this will mean an extra 3 NOT gates and a mux block for the demux-8 case. But it will have a smaller counter. The alternative would require a number of registers and a much more complicated conj_fix block. So I think this is the simplest fix. I will try'n implement it today and check it into GIT this evening.
corr_output_format.ods
Description: application/vnd.oasis.opendocument.spreadsheet
Jason On 20 Oct 2010, at 18:50, Jack Hickish wrote: > 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> > >
