EOVSA STATE FRAME ASSEMBLY, DISTRIBUTION, AND SYNCHRONIZATION Gelu Nita NJIT 15-17 MARCH 2012 EOVSA...
-
Upload
jocelyn-pierce -
Category
Documents
-
view
214 -
download
2
Transcript of EOVSA STATE FRAME ASSEMBLY, DISTRIBUTION, AND SYNCHRONIZATION Gelu Nita NJIT 15-17 MARCH 2012 EOVSA...
![Page 1: EOVSA STATE FRAME ASSEMBLY, DISTRIBUTION, AND SYNCHRONIZATION Gelu Nita NJIT 15-17 MARCH 2012 EOVSA PDR MEETING 1.](https://reader036.fdocuments.us/reader036/viewer/2022083008/56649f3d5503460f94c5dd91/html5/thumbnails/1.jpg)
1
EOVSA STATE FRAME ASSEMBLY, DISTRIBUTION, AND SYNCHRONIZATION Gelu Nita
NJIT
15-17 MARCH 2012EOVSA PDR MEETING
![Page 2: EOVSA STATE FRAME ASSEMBLY, DISTRIBUTION, AND SYNCHRONIZATION Gelu Nita NJIT 15-17 MARCH 2012 EOVSA PDR MEETING 1.](https://reader036.fdocuments.us/reader036/viewer/2022083008/56649f3d5503460f94c5dd91/html5/thumbnails/2.jpg)
EOVSA PDR MEETING 2
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.
15-17 MARCH 2012
![Page 3: EOVSA STATE FRAME ASSEMBLY, DISTRIBUTION, AND SYNCHRONIZATION Gelu Nita NJIT 15-17 MARCH 2012 EOVSA PDR MEETING 1.](https://reader036.fdocuments.us/reader036/viewer/2022083008/56649f3d5503460f94c5dd91/html5/thumbnails/3.jpg)
EOVSA PDR MEETING 3
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.
15-17 MARCH 2012
![Page 4: EOVSA STATE FRAME ASSEMBLY, DISTRIBUTION, AND SYNCHRONIZATION Gelu Nita NJIT 15-17 MARCH 2012 EOVSA PDR MEETING 1.](https://reader036.fdocuments.us/reader036/viewer/2022083008/56649f3d5503460f94c5dd91/html5/thumbnails/4.jpg)
EOVSA PDR MEETING 4
STATE FRAME SYNCHRONIZATION
One 50 PPS Time Slot
15-17 MARCH 2012
Accumulation (18.773ms)
Transition interval
1ms
50 PPS tick
Tuning
50 PPS tick
Tuning
1ms
![Page 5: EOVSA STATE FRAME ASSEMBLY, DISTRIBUTION, AND SYNCHRONIZATION Gelu Nita NJIT 15-17 MARCH 2012 EOVSA PDR MEETING 1.](https://reader036.fdocuments.us/reader036/viewer/2022083008/56649f3d5503460f94c5dd91/html5/thumbnails/5.jpg)
EOVSA PDR MEETING 5
STATE FRAME SYNCHRONIZATION
One Second State Frame Interval
15-17 MARCH 2012
1 PPS tick
State Frame Start
1 PPS tick
SF Start
I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I
50 PPS ticks
![Page 6: EOVSA STATE FRAME ASSEMBLY, DISTRIBUTION, AND SYNCHRONIZATION Gelu Nita NJIT 15-17 MARCH 2012 EOVSA PDR MEETING 1.](https://reader036.fdocuments.us/reader036/viewer/2022083008/56649f3d5503460f94c5dd91/html5/thumbnails/6.jpg)
EOVSA PDR MEETING 6
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.
15-17 MARCH 2012
![Page 7: EOVSA STATE FRAME ASSEMBLY, DISTRIBUTION, AND SYNCHRONIZATION Gelu Nita NJIT 15-17 MARCH 2012 EOVSA PDR MEETING 1.](https://reader036.fdocuments.us/reader036/viewer/2022083008/56649f3d5503460f94c5dd91/html5/thumbnails/7.jpg)
EOVSA PDR MEETING 7
STATE FRAME ASSEMBLY STEPS AND LATENCY
15-17 MARCH 2012
All distributed EOVSA control and monitor real-time subsystems gather and pack sub-frame information corresponding to 50 20ms time slots
1PPS tick: Start of a new state frame assembly
Previous second sub-frame data is sent to ACC
1PPS tick TBD x 50 PPS ticks
All previous second sub-frames are assembled together
TBD x 50 PPS ticks
State Frame is available for being retrieved upon request from the State Frame Server
State Frame Latency: 1s+TBD x 50 PPS ticks
![Page 8: EOVSA STATE FRAME ASSEMBLY, DISTRIBUTION, AND SYNCHRONIZATION Gelu Nita NJIT 15-17 MARCH 2012 EOVSA PDR MEETING 1.](https://reader036.fdocuments.us/reader036/viewer/2022083008/56649f3d5503460f94c5dd91/html5/thumbnails/8.jpg)
EOVSA PDR MEETING 8
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
15-17 MARCH 2012
![Page 9: EOVSA STATE FRAME ASSEMBLY, DISTRIBUTION, AND SYNCHRONIZATION Gelu Nita NJIT 15-17 MARCH 2012 EOVSA PDR MEETING 1.](https://reader036.fdocuments.us/reader036/viewer/2022083008/56649f3d5503460f94c5dd91/html5/thumbnails/9.jpg)
EOVSA PDR MEETING 9
EXAMPLE: EOVSA SUBSYSTEM TESTBED (EST) STATE FRAME TEMPLATE
<Cluster>
<Name>STATEFRAME</Name>
<NumElts>17</NumElts>
<DBL>
<Name>Timestamp</Name>
<Val>0.00000000000000</Val>
</DBL>
<I32>
…......more here…………..
<Array>
<Name>BAND</Name>
<Dimsize>10</Dimsize>
<I16>
<Name></Name>
<Val></Val>
</I16>
</Array>
……………more here………
<Array>
<Name>uvw</Name>
<Dimsize>3</Dimsize>
<Dimsize>10</Dimsize>
<DBL>
<Name></Name>
<Val></Val>
</DBL>
</Array>
……………more here……
<Cluster>
<Name>Trackstatus</Name>
<NumElts>4</NumElts>
<DBL>
<Name>Timestamp</Name>
<Val>0.00000000000000</Val>
</DBL>
<I32>
<Name>Antenna1</Name>
<Val>0</Val>
</I32>
<I32>
<Name>Antenna2</Name>
<Val>0</Val>
</I32>
<I32>
<Name>Antenna3</Name>
<Val>0</Val>
</I32>
</Cluster>
……………more here……
</Cluster>
15-17 MARCH 2012
![Page 10: EOVSA STATE FRAME ASSEMBLY, DISTRIBUTION, AND SYNCHRONIZATION Gelu Nita NJIT 15-17 MARCH 2012 EOVSA PDR MEETING 1.](https://reader036.fdocuments.us/reader036/viewer/2022083008/56649f3d5503460f94c5dd91/html5/thumbnails/10.jpg)
EOVSA PDR MEETING 10
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 Floating-Point Number
32 SGL FLOAT
Double-Precision Floating-Point Number
64 DBL DOUBLE
Single-Precision Complex Floating-Point Number
64 CSG COMPLEX
15-17 MARCH 2012
![Page 11: EOVSA STATE FRAME ASSEMBLY, DISTRIBUTION, AND SYNCHRONIZATION Gelu Nita NJIT 15-17 MARCH 2012 EOVSA PDR MEETING 1.](https://reader036.fdocuments.us/reader036/viewer/2022083008/56649f3d5503460f94c5dd91/html5/thumbnails/11.jpg)
EOVSA PDR MEETING 11
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)>
15-17 MARCH 2012
![Page 12: EOVSA STATE FRAME ASSEMBLY, DISTRIBUTION, AND SYNCHRONIZATION Gelu Nita NJIT 15-17 MARCH 2012 EOVSA PDR MEETING 1.](https://reader036.fdocuments.us/reader036/viewer/2022083008/56649f3d5503460f94c5dd91/html5/thumbnails/12.jpg)
EOVSA PDR MEETING 12
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
15-17 MARCH 2012
![Page 13: EOVSA STATE FRAME ASSEMBLY, DISTRIBUTION, AND SYNCHRONIZATION Gelu Nita NJIT 15-17 MARCH 2012 EOVSA PDR MEETING 1.](https://reader036.fdocuments.us/reader036/viewer/2022083008/56649f3d5503460f94c5dd91/html5/thumbnails/13.jpg)
EOVSA PDR MEETING 13
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.
15-17 MARCH 2012