main.cpp File Reference

Functions
Architecture	Streams_And_Synchronisation__ ()
	Retrieve data from streams and process together once per epoch.
void	avoidCollisions (ReceiverMap &receiverMap)
void	mainOncePerEpochPerStation (Receiver &rec, Network &net, bool &emptyEpoch, KFState &remoteState)
	Perform operations for each station This function occurs in parallel with other stations - ensure that any operations on global maps do not create new entries, as that will destroy the map for other processes.
void	mainOncePerEpochPerSatellite (Trace &trace, GTime time, SatSys Sat, KFState &kfState, KFState &remoteKF)
void	cullData (GTime time)
void	mainOncePerEpoch (Network &pppNet, Network &ionNet, ReceiverMap &receiverMap, GTime time)
void	mainPostProcessing (Network &pppNet, Network &ionNet, ReceiverMap &receiverMap)
	Perform any post-final epoch calculations and outputs, then begin reverse smoothing and tidy up.
void	tryExitGracefully (int signum)
int	main (int argc, char **argv)

Function Documentation

avoidCollisions()

void avoidCollisions

(

ReceiverMap &

receiverMap

)

Here is the call graph for this function:

Here is the caller graph for this function:

cullData()

void cullData

(

GTime

time

)

Here is the call graph for this function:

Here is the caller graph for this function:

main()

int main	(	int	argc,
		char **	argv )

mainOncePerEpoch()

void mainOncePerEpoch	(	Network &	pppNet,
		Network &	ionNet,
		ReceiverMap &	receiverMap,
		GTime	time )

Here is the call graph for this function:

Here is the caller graph for this function:

mainOncePerEpochPerSatellite()

void mainOncePerEpochPerSatellite	(	Trace &	trace,
		GTime	time,
		SatSys	Sat,
		KFState &	kfState,
		KFState &	remoteKF )

Here is the call graph for this function:

Here is the caller graph for this function:

mainOncePerEpochPerStation()

void mainOncePerEpochPerStation	(	Receiver &	rec,
		Network &	net,
		bool &	emptyEpoch,
		KFState &	remoteState )

Perform operations for each station This function occurs in parallel with other stations - ensure that any operations on global maps do not create new entries, as that will destroy the map for other processes.

Variables within the rec object are ok to use, but be aware that pointers from the within the receiver often point to global variables. Prepare global maps by accessing the desired elements before calling this function.

Here is the call graph for this function:

Here is the caller graph for this function:

mainPostProcessing()

void mainPostProcessing	(	Network &	pppNet,
		Network &	ionNet,
		ReceiverMap &	receiverMap )

Perform any post-final epoch calculations and outputs, then begin reverse smoothing and tidy up.

Here is the call graph for this function:

Here is the caller graph for this function:

Streams_And_Synchronisation__()

Architecture Streams_And_Synchronisation__

(

)

Retrieve data from streams and process together once per epoch.

In order to be capable of real-time and post-processed execution, the pea treats all observation inputs as streams. These streams are created with a stream source type, and a parser, with the separation of these strategies allowing for far more reusable code, and immediate extension of inputs from simply files, to HTTP, TCP, Serial, Pipes etc.

The fundamental tick of the pea is the epoch_interval, which drives all major processing steps. Once an initial epoch has been designated the pea requests data for the next epoch from each stream. The streams either respond with the data, or with a flag indicating the data may be available later, or will never be available.

Various configuration parameters define the exact flow through the synchronisation code, however once all data is available, or no more is expected, or a timeout has occurred, the epoch is considered synchronised and processing is performed.

Unlike observation streams, which provide data up until the requested epoch time, other streams such as navigation streams parse all data available to them, and output any values to global maps, which may be later accessed as required by other components.

The synchronisation process parses all streams sequentially, without multithreading, so map collisions are not expected.

Here is the caller graph for this function:

tryExitGracefully()

void tryExitGracefully

(

int

signum

)

Here is the call graph for this function:

Here is the caller graph for this function: