Digital Packaging Processor Interface Details Gordon Hurford Nov 8, 2011

1. Digital Packaging Processor Interface DetailsGordon HurfordNov 8, 2011 EOVSA Technical Design Meeting - NJIT

2. DPP Interface Overview Interim Data Base DPP <P>, <P2>, Correlations Correlator Start / End Scan Commands Scan-independent Calibration Parameters Miriad format ACC Scan Parameters Frame parameters State Frame Frame status report Internal RFI Database RFI results 0.5 s timing tick 0.02 s timing tick

3. DPP-Correlator Interface • 4096 x 2 x16^2 8-byte visibilities • 4096 x 2 x 16 8-byte <P2> values •  9 MB / data frame  450 MB/s • Two Dedicated 10 Gb Ethernet link(s) • One for each polarization?? • Separate 1 Gb ethernet link for P2 data • Interface architecture driven by correlator design

4. DPP State Frame Interface • Specifics TBD • Client/server model  DPP requests data • State frame is synchronized with spectral frame • Two types of data • Scan-specific ‘header’ data • State frame that updates every second • DPP will assume ‘header’ parameters are stable during scan • DPP reads state frame every second • Assume state frame has flags indicating update state so DPP can verify data are current • DPP updates state frame with processing status • Pre-reading from a rotating buffer relieves timing constraints

5. DPP – ACC Interface • Low data volume • Shared Ethernet link • ACC issues start / end scan commands • ACC provides scan-independent calibration parameters (or should these be in state frame header?)

6. DPP Timing Ticks • Both 0.5s and 20 ms ticks are desirable • Enables DPP to reliably associate correlator output with correct data frame • Enables DPP to determine if timing overrun has occurred

7. DPP – Interim Data Base Interface • DPP writes directly to dual-port IDB disk • DPP writes data in a Miriad-compatible format • Science frame ~1.1 MB • (1 second, 500 spectral channels, 2 polarizations, 4 byte FP, 16^2 visibility components, +20% overhead) 1.1 MB/s  50 GB/day IDB disk is also accessible to a data analysis platform. • Data writing has priority

8. IDB Issue • A Miriad ‘record’ contains all frequencies in a predefined spectrum for a specified time/baseline •  Need to time shift visibility phases to a reference time • Conflicting goals: • IDB format should be Miriad compatible with EOVSA-specific exceptions minimized • IDB format should be compact • Need support for Type III mode where a subset of frequencies have <1s time resolution • Options for dealing with high time resolution data: • Use lots of ‘fill’ data – bulks up IDB • Redefine spectral parameters twice per second – extra proecessing??? • Use non-standard kluge to record high time resolution data - ugh • Simultaneously create two Miriad databases (e.g. 1s with full spectrum and 0.2 s with partial spectrum)

9. IDBcontents.xls