I just noticed a bug in the model I sent: I am unpacking a 18_17 complex number as an 8_7 complex number. However, this does not affect the fact that the two pol0 outputs are different. I am running the same test with the pink blocks, and it seems there is a small difference between the two pol0 outputs there as well, so this may be a very old bug, or it may be something flawed with my test. Glenn
On Fri, Sep 19, 2008 at 12:58 AM, G Jones <[email protected]> wrote: > Attached is a simple 7.1 model that illustrates the problem. The out0 from > each fft is different even though the pol0 input is the same. The only > difference is the pol1 input. > The green block implementation is significantly different from the pink as > far as the reordering, so this may be difficult to track down > Glenn > > > On Thu, Sep 18, 2008 at 6:14 PM, G Jones <[email protected]> wrote: > >> Thanks for clarifying Aaron, I will go through the block carefully tonight >> and see if I can trace down the "cross-coupling." >> Glenn >> >> >> On Thu, Sep 18, 2008 at 6:12 PM, Aaron Parsons < >> [email protected]> wrote: >> >>> Your description of what the FFT block *should* do for n_inputs = 2^0 >>> is correct. Assuming the output has been correctly descrambled into >>> to separate the spectra of the two inputs, one input should not >>> influence the other's spectrum in any way. This has been tested >>> extensively in the library as I left it last summer. If this is not >>> the behavior that you are seeing, then I suspect an error in one of >>> the mask scripts has been introduced during this massive code >>> migration. >>> >>> As for the PFB FIR, it is correct that in "biplex mode" it simply >>> makes two copies of the same polyphase filter. >>> >>> On Thu, Sep 18, 2008 at 8:19 PM, G Jones <[email protected]> >>> wrote: >>> > Hello, >>> > I am trying to use the green FFT block with number of simultaneous >>> inputs >>> > set to 0. My understanding was that this makes a biplex fft that >>> processes >>> > two independant data streams in parallel, thus the pol0 input should >>> have x0 >>> > x1 x2... and pol1 should have y0 y1 y2 and then the pol0 output will >>> just >>> > have frequencies related to pol0. However, when I simulate this, I find >>> that >>> > the two inputs are interacting. If I set one input to a constant, the >>> output >>> > is significantly different than if I connect the two inputs together >>> (in >>> > which case I should get two identical copies at the output. >>> > I did notice in the packetized correlator iBOB design (using pink >>> blocks) >>> > the pfb_fir block preceeding the fft is set to biplex mode, but I had >>> > assumed this didn't change the functionality of the block since a >>> biplex >>> > pfb_fir block should be equivalent two single input pfb_fir blocks. >>> > Can someone more clearly explain the functionality of the FFT block? >>> > Thank you, >>> > Glenn >>> > >>> >>> >>> >>> -- >>> Aaron Parsons >>> >>> 510-406-4322 (cell) >>> 787-878-2612 x329 (arecibo office) >>> 787-721-3991 (home) >>> >> >> >
