EOVSA STATE FRAME
ASSEMBLY, DISTRIBUTION,
AND SYNCHRONIZATION
Gelu Nita
NJIT
EOVSA PDR MEETING
15-17 MARCH 2012
1
EOVSA STATE FRAME DEFINITION AND
SPECIFICATIONS
 Describes the state of the system during the preceding second of
operation in a form of a fixed-length structure that does not change
during system operation, but may be changed as the result of a software
update.
 May contain scalar parameters valid for the entire second, or arrays of
parameters corresponding to a predefined number of sub-second time
slots.
 It is provided, upon request, in a form of a binary package that is
formatted according to a predefined data template, to any client that
connects to the State Frame Server via TCP/IP during a predefined time
interval in which any new state frame resides in a fixed length memory
buffer before being transferred to the RDBMS system.
EOVSA PDR MEETING
15-17 MARCH 2012
2
STATE FRAME SYNCHRONIZATION
 The EOVSA State Frame will be assembled based on a 50 PPS timing source





that will be derived from, and aligned with, the1PPS GPS timing source.
Each State Frame will be uniquely identified by the state frame 1 PPS
Timestamp assigned by the EOVSA master clock.
Each State Frame will be composed from 50 time bins aligned with the 50
PPS timing source.
Any EOVSA state switch, such tunings, attenuation changes, etc., will occur
exactly on the rising edge of a 50 PPS trigger.
It is planned for all transition states not to last more than 1ms after the 50
PPS trigger.
The EOVSA Correlator must synchronize its accumulations such as to be
started and ended within the 19 ms stationary time interval laying between
two subsequent 50 PPS ticks.
EOVSA PDR MEETING
15-17 MARCH 2012
3
STATE FRAME SYNCHRONIZATION
 One 50 PPS Time Slot
50 PPS tick
50 PPS tick
Tuning
Tuning
1ms
Accumulation (18.773ms)
1ms
Transition interval
EOVSA PDR MEETING
15-17 MARCH 2012
4
STATE FRAME SYNCHRONIZATION
 One Second State Frame Interval
1 PPS tick
1 PPS tick
State Frame Start
SF Start
50 PPS ticks
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
EOVSA PDR MEETING
15-17 MARCH 2012
5
EOVSA STATE FRAME ASSEMBLY
 The EOVSA State Frame will be assembled by the real-time Array
Control Computer, which will gather partial information from the Field
Antenna Controllers, the Downconverter System, the LO System, and
from the Task Scheduler, and combine everything in a fixed-length data
structure that may contain, if needed, pre allocated slots that may be
later filled with post-assembly parameters not yet available, such as
acknowledgement flags that other data processing EOVSA subsystems
may need to set at a later time.
 On the 1 PPS tick, the fully assembled state frame will be stored in the
State Frame Server’s memory buffer, when it will reside and be available
to be served upon request, until all post-processing tags are filled in, or
the time comes for being transferred to the RDBMS system.
EOVSA PDR MEETING
15-17 MARCH 2012
6
STATE FRAME ASSEMBLY STEPS AND LATENCY
1PPS tick: Start of a new state frame assembly
All distributed EOVSA control and monitor real-time subsystems gather and pack subframe information corresponding to 50 20ms time slots
1PPS tick
Previous second
sub-frame data is
sent to ACC
TBD x 50 PPS ticks
TBD x 50 PPS ticks
All previous second
sub-frames are
assembled together
State Frame is available for being retrieved
upon request from the State Frame Server
State Frame Latency: 1s+TBD x 50 PPS ticks
EOVSA PDR MEETING
15-17 MARCH 2012
7
SERVER-CLIENT STATE FRAME TEMPLATE
TRANSACTION
 Before starting to receive state frames from the server, any client must
obtain from the State Frame Server a description of the most recent
state frame structure in a form of a self-describing template generated
by the server at its start-up.
 OPTIONS:
 GENERAL PURPOSE TCP/IP SOCKET (Needs more transaction steps and a
request-response protocol to be implemented)
 DEDICATED TCP/IP SOCKET (Much simpler implementation since the server
would know in advance what the client is waiting for)
 An variable-length XML-based convention will be used to describe the
fixed-length state frame structure
EOVSA PDR MEETING
15-17 MARCH 2012
8
EXAMPLE: EOVSA SUBSYSTEM TESTBED
(EST) STATE FRAME TEMPLATE
<Cluster>
……………more here………
</DBL>
<Name>STATEFRAME</Name>
<Array>
<I32>
<NumElts>17</NumElts>
<Name>uvw</Name>
<Name>Antenna1</Name>
<DBL>
<Dimsize>3</Dimsize>
<Val>0</Val>
<Name>Timestamp</Name>
<Dimsize>10</Dimsize>
</I32>
<Val>0.00000000000000</Val>
<DBL>
<I32>
</DBL>
<Name></Name>
<Name>Antenna2</Name>
<I32>
<Val></Val>
<Val>0</Val>
…......more here…………..
</DBL>
</I32>
<Array>
</Array>
<I32>
<Name>BAND</Name>
……………more here……
<Name>Antenna3</Name>
<Dimsize>10</Dimsize>
<Cluster>
<Val>0</Val>
<I16>
<Name>Trackstatus</Name>
</I32>
<Name></Name>
<NumElts>4</NumElts>
</Cluster>
<Val></Val>
<DBL>
……………more here……
</I16>
<Name>Timestamp</Name>
</Cluster>
</Array>
<Val>0.00000000000000</Val>
EOVSA PDR MEETING
15-17 MARCH 2012
9
LABVIEW-IDL FIXED-LENGTH NUMERICAL
DATA TYPE CORRESPONDENCE
LabVIEW Numeric Data Type
#bits
Symbol
IDL Equivalent Data Type
8-bit Integer
8
I8
NONE
16-bit Integer
16
I16
INT
32-bit Integer
32
I32
LONG
64-bit Integer
64
I64
LONG64
Unsigned 8-bit Integer
8
U8
BYTE
Unsigned 16-bit Integer
16
U16
UNSIGNED
Unsigned 32-bit Integer
32
U32
ULONG
Unsigned 64-bit Integer
64
U64
ULONG64
Single-Precision FloatingPoint Number
Double-Precision FloatingPoint Number
Single-Precision Complex
Floating-Point Number
32
SGL
FLOAT
64
DBL
DOUBLE
64
CSG
COMPLEX
EOVSA PDR MEETING
15-17 MARCH 2012
10
THREE IMPORTANT DETAILS THAT WILL NOT BE
CONTAINED BY THE STATE FRAME TEMPLATE
 Data will be transmitted by the State Frame Server to all its clients as a
binary stream having a big-endian format
 The data block corresponding to an array data type will be always
preceded by as many I32-slots as needed to store each of the array
dimensions. This information would be redundant but required by the
internal memory mapping at State Frame Server side.
 Multidimensional arrays will follow a row major convention
Therefore, the state frame data section corresponding to an array that would be
represented by IDL as
arr=bindgen(2,3)
would be transmitted as
<I32(3)><I32(2)>< U8(0)>< U8(1)>< U8(2)>< U8(3)>< U8(4)>< U8(5)>
EOVSA PDR MEETING
15-17 MARCH 2012
11
SERVER-CLIENT STATE FRAME
TRANSACTION (PART I)
 OPTIONS:
 GENERAL PURPOSE TCP/IP SOCKET (Needs more transaction steps and a
request-response protocol to be implemented)
 DEDICATED PORT (Much simpler implementation)
 TRANSACTION STEPS:
 Server listens at a port for a client to connect
 Client connects and asks for a specific state frame identified by an 1PPS timestamp
 Server searches the buffer and sends the matched state frame
 Client acknowledges receiving it and closes connection with the server at its side
 Server receives acknowledgement and closes connection with the client at its side
EOVSA PDR MEETING
15-17 MARCH 2012
12
SERVER-CLIENT STATE FRAME
TRANSACTION (PART II)
 OPTIONS:
 Server transmits the entire state frame to its clients (Simple implementation compatible to using
a dedicated state frame socket)
 Server transmits only the relevant information to its clients (requires some overhead associated
with extracting the relevant information and would need a request/response protocol or an
individualized dedicated socket for each type of client )
 The state frame may contain dedicated slots for:
 Flagging the current transaction status corresponding to each of its registered clients (sent,
delivered, processed, etc. ?)
 Flagging the updating status of those fields needed to be updated by its clients (waiting, updated,
etc. ?)
 State Frame updating transactions:
 If a client needs to update a state frame field, the client will send only the relevant information
tagged by the 1PPS timestamp of the state frame to be updated
 Such transactions may need dedicated TCP/IP communication channels independent of the state
frame channel.
 The updated information would be sent by the clients having the same format as the one
described in the corresponding slot of state frame template.
EOVSA PDR MEETING
15-17 MARCH 2012
13