T-engine data verification

[jaycedowell]

These are a large departure from what is happening with ADP at LWA-SV but similar-ish to what's at OVRO-LWA. Are all of the changes actually working? Is the PFB inverter inverting correctly?

[jaycedowell]

Things are moving in the correct direction (now), both with and without the PFB inverter. I have had a few DRX recordings that look ok and have good power levels. The F-engine PFB structure largely goes away when the inverter is turned on. The T-engines respond to DRX commands. Data transport looks ok.

[jaycedowell]

This isn't strictly a data verification thing but https://github.com/lwa-project/ng_digital_processor/commit/6592a74b604d618de308f185f582b7f29431c9cc replaces the FFT-map-IFFT call with a single map call. Hopefully this will help with getting all four T-engines running with PFB inversion.

[jaycedowell]

We've detected PSR B1919+21:

Things can't be too bad.

[jaycedowell]

We've also had a successful fringe test. From @GregBTaylor:

Jayce correlated 60 seconds of LWA1 + LWA-SV + LWA-NA observing Cyg A. Good SNR on the fringe-fitting so that’s a great start. Delays are consistent between X and Y polarizations, but not between IFs which is a little puzzling. The difference is only about 10 nsec for LWA-SV but is about 80 nsec for LWA-NA. I broke up the 60 seconds into 4 pieces of 15 seconds to see how consistent the solutions are.

I’m assuming that: 51 = LWA1 52 = LWA-NA 53 = LWA-SV

Residual delay, 1000 = 10000.000 nanoseconds Stokes = X IF = 1 Freq = 0.044200000 GHz

Time Source --51--52--53

Day # 0 22:40:17.5 CYGA 0 -19 -4 22:40:32.5 CYGA 0 -19 -4 22:40:47.5 CYGA 0 -20 -3 22:41:02.5 CYGA 0 -21 -3

Residual delay, 1000 = 10000.000 nanoseconds Stokes = X IF = 2 Freq = 0.064200000 GHz

Time Source --51--52--53

Day # 0 22:40:17.5 CYGA 0 -13 -5 22:40:32.5 CYGA 0 -12 -5 22:40:47.5 CYGA 0 -11 -5 22:41:02.5 CYGA 0 -12 -5

NB: The antenna-number-to-station mapping should be 51=LWA1, 52=LWA-SV, and 53=LWA-NA.

[jaycedowell]

At some point we should try https://github.com/lwa-project/ng_digital_processor/tree/new_drx_packetizer.

[jaycedowell]

new_drx_packetizer seems to be working (now). working = no exceptions thrown and data coming out

Update: No luck detecting PSR B0329+54 this afternoon using 300 s of data at 38 and 74 MHz.

Update: Still no luck detecting PSR B0329+54, now with ~800 s of data. Could be time to roll back to main to see if that still works.

[jaycedowell]

Maybe new_drx_packetizer is working. Here's a detection of PSR 0950+08 with it: It's not the best detection but a similar run with the packetizer in main yielded a 4.6-σ detection in a similar amount of time.

[jaycedowell]

I also tried to recreate the original B1919+21 detection posted here. I ended up with:

It's there but it's not 18-σ. Maybe it's the calibration?

[jaycedowell]

After making some progress on #30 I decided to re-visited how the T-engine data was looking. I was concerned that maybe @ctaylor-physics's issue at https://github.com/lwa-project/commissioning/issues/14 was actually an indication of massive packet loss on the switch caused by how we were sending data to the T-engine.

Another try on B1919+21 this morning yielded: Perfectly acceptable. I also had a good detection on the 65 MHz tuning:

I should also note that this was not done with the new_drx_packetizer branch.

[jaycedowell]

Closing this for now since it looks like new_drx_packetizer won't be going on the telescope any time soon.