SNAP2 packet formatting

[jaycedowell]

There looks to be some funny business with the chan_block_id field in the packets. The lowest channel number (chan0) in a set appears to come out at a chan_block_id of nchan_tot//nchan-2 rather that the zero I would expect.

[jaycedowell]

I've hacked a fix into src/formats/snap2.hpp which shifts the IDs into the correct places. Are the data correctly oriented spectrally in the "DRX" pipelines?

[jaycedowell]

There is another hack in src/formats/snap2.hpp that relaxes the packet validation so that pkt->nsrc <= _nsrc is used instead of a pkt->nsrc == _nsrc. I guess this allows similar behavior on the Bifrost side to the SNAP2 packet spoofing feature?

[jaycedowell]

Now that I have pipelines the data look to be mostly zeros. Is this related to the packet labeling problem (as in that is a symptom of a larger problem) or do I have bad RF power/SNAP2 configuration settings?

[jaycedowell]

Now that I have pipelines the data look to be mostly zeros. Is this related to the packet labeling problem (as in that is a symptom of a larger problem) or do I have bad RF power/SNAP2 configuration settings?

This seems like a bad combination of FFT shift and equalizer coefficients. I used both the SNAP2's corr module and the equalizer test vector (enabled with a eq.tvg_enable()) to verify that there are non-zero post-quantization data.

[jaycedowell]

There's a potential fix for this chan_block_id problem at https://github.com/realtimeradio/caltech-lwa/commit/fbec68b4a33be18ca7b7b9205ebc4d11708d9ea8. I'm waiting on the system to stabilize before I try it.

[jaycedowell]

https://github.com/realtimeradio/caltech-lwa/commit/fbec68b4a33be18ca7b7b9205ebc4d11708d9ea8 seems to be working.