carma::loberotator Namespace Reference

The loberotator subsystem controls and monitors the loberotator boards. More...

Classes
class	Chassis
	Provides storage for Loberotator objects. More...
class	Loberotator
	Loberotator implementation. More...
interface	LoberotatorControl
	LoberotatorControl interface More...
class	LoberotatorMaster
	Carma Loberotator CAN Master class. More...
class	SimData
	Simulated data generator class. More...
class	SimIntegerData
	Simulated integer data generator class. More...

Variables
const string	LOBEROTATOR_NAME = "carma.loberotator.LoberotatorControl"
	The CARMA canonical name for this Distributed Object. More...

Detailed Description

The loberotator subsystem controls and monitors the loberotator boards.

These boards provide phase tracking of sources by applying phase and frequency information to a 50 MHz carrier that is added to the reference LO, based on inputs from the DelayEngine.

Critical details in dealing with the hardware:

• The phase and rate are updated every half second and should be sent in the middle of the blanking frame, i.e., 250msec after the integral half second.
• The Janz hardware on the Linux host has an output buffer with a capacity of 400 messages.
• The CANnode XAC hardware has a buffer for each channel that is only one deep. Two consecutive messages must not be sent to a node or it will scramble the contents.
• The bus time for a single message is about 120 microseconds, giving about 8 messages per millisecond. This can used to advantage by placing other messages inbetween any two messages to the same node.
• Interference between random CANbus control messages and the half second phase and rate updates can be handled by sending a bogus guard message before any control command. This uses the output queue and the bus timing to give a 120usec delay between receipt of any two messages at the XAC.
• Changing the number of channels in the system (Chassis::N_CHAN) could have a deleterious effect on the system because it changes the timing.

The relevant classes containing public interfaces of interest to client programs:

• LoberotatorControl is the distributed object interface. This the what the DelayEngine talks to.

• carmaLoberotatorHost is the program to start the Loberotator class.

The canbus interface for the Loberotator systems is documented in CANBus API No. 113.

See Also

http://www.mmarray.org/project/system/CanAPI/Docs/API_113_LobeRotatorVerG.pdf

http://www.mmarray.org/project/WP/LobeRotator/hw/

http://www.mmarray.org/project/WP/LobeRotator/sw/

Variable Documentation

const string carma::loberotator::LOBEROTATOR_NAME = "carma.loberotator.LoberotatorControl"

The CARMA canonical name for this Distributed Object.

This is the name used to register with the nameserver.

Definition at line 32 of file LoberotatorControl.idl.