EROS5 Command Reference
Command Reference
Extracted from comments in EROS5 source files 03-Feb-2020.
allowantenna --
Start respecting pointing commands and clockdelay
Synopsis
allowantenna
See also
inhibitantenna
argv --
Return the list of arguments of the latest runexperiment command.
Synopsis
argv
Description
-> The argv command makes the parameters given in the
runexperiment and testexperiment commands available to the
called script. If the runexperiment command was
U: runexperiment myexp 12:30 1 abc 3.3
then argv will return the 3-element list {1 "abc" 3.3}.
-> Typically, the parameters are intended as arguments of the main
BLOCK in an ELAN file. The BLOCK definition might look like
---------------------------------------------------
BLOCK MainBlock { x y z } {
...
}
---------------------------------------------------
In the ELAN file, MainBlock could then be invoked as
callblock MainBlock {*}[argv]
which typically would be the last line of the ELAN file.
-> Note that using the special block-defining command MAIN, which
causes that block to be called automatically by the
runexperiment command, one does not need to use the argv
command at all.
armradar --
Set radar controller start address and registers and set the controller
waiting for a start pulse.
Synopsis
armradar <RCNAME> prog<N> ?-lc <LC>? ?-s <SC>?
armradar <RCNAME> prog<N> ?-iper <IPER> -rep <REP>?
Description
-> If the RC is not running, this command sets the RC state to "armed",
where it waits for the start pulse from the timing system, see
startradar. If the RC is already in the running state, no change
in the "running" state takes place. The RC's start address register
is loaded with the value found for prog<N> in the radarinfo
database. In addition, the loopcounter and synccounter registers can
be loaded, either by giving a numeric value, or by referring to the
radarinfo data. As an alternative, the loopcounter and synccounter
registers can also be loaded by specifying integration period and
repetition period, in which case EROS uses radarloops to compute
the corresponding LC and SC values. The register loadings take
effect for next integration period.
-> Note that prog<N> is now a required parameter (earlier it was possible
to use -a SA instead). The names prog<N> are used in printexperiment
and printradar commands to indicate which RC program is currently
running, and are used as record labels in radarinfo. There is
always a start address (SA) associated with a prog<N>, kept in
radarinfo. This address is now written to the RC's start address
register.
-> The armradar command can be used both when the RC is running or when
the RC is stopped (or armed). For a running RC, typical use would be
to change to an other, pre-loaded, program without stopping the RC
first.
-> <RCNAME> = rx|rec|tx|tra|ion|pla|all.
-> prog<N> is a string like "prog2" or "prog_mytx", and must exist in
radarinfo (see radarinfo and loadradar).
-> <LC> is the number of loops in the integration period,
(the value LC-1 is poked to the LC register).
-> <SC> is the sync count value.
-> <IPER> is the required integration period. An embedded unit "s" or "us"
can be used; if missing, "s" is assumed.
-> <REP> is the repetition period of progN. An embedded unit
"s" or "us" can be used; if missing, "us" is assumed.
-> The parameters <LC>, <SC>, and <REP> can also be "@", in which
case the corresponding value is taken from radarinfo. Note
that <IPER> cannot be "@", but can be an radarinfo @-variable
(see radarinfo).
Examples
armradar rec prog2
armradar pla prog1 -l 10 -s 0
armradar tra prog2 -l @ -s @
armradar ion prog1 -iper 5.0s -rep 10000.0us
See also
loadradar radarinfo startradar stopradar printradar
at --
Schedule a commant to be executed at a specified time.
Synopsis
at
at info ?<Id>?
at cancel <Id>
at <time spec> <script>
Description
-> This command is allowed only on the local EROS console. You can
schedule a remote command with at, but you cannot give at as a
remote command to another site (but see the last item below).
-> Note the use of braces in the <script>. For instance,
at 11:29 runexp tau1 fullminute ;# ???
would give an error. The script can contain multiple commands, but
even when there is only a single command, the braces are required,
see the examples.
-> A multicommand script can be input on multiple lines.
-> A script containing <esc> is disregarded, so if you are typing a
multicommand script and want to cancel the input, just type <esc>
and terminate the input with the righthand brace. (Depending on
what "readline" EROS Console uses, it might also be possible to
use Ctrl-C).
-> Note that if there are syntax errors in the command, those will
be detected only when the scheduled command is executed.
-> Scheduled commands can be inspected using at without parameters,
or using
at info
which lists all scheduled commands and their <Id>s.
-> Scheduled commands can be cancelled one by one using
at cancel <Id>
or cancelled all at once by using
at cancel all
-> The at scheduler runs within the local EROS Console process, so a
brute-force way to clear all pending at commands is to restart the
Console using
eros restart console
which can be given also as a remore command (but don't).
Examples
at 11:29:30 {runexp /kst/exp/tau1/tau1 fullminute cp1}
at "19-Feb 03:00" {stopexperiment; pointdirection 180 89}
at 11:29:45 {sod stopexp}
at info
at info #34
at cancel #34
AT --
Suspend ELAN file processing until a specified instant of UTC.
Synopsis
AT <time spec>
Description
-> Suspend ELAN file execution until UTC is greater than or equal to the time
implied by <time spec>.
-> The <time spec> can be any time specication accepted by the
ScanExpTime command.
-> The <time spec> is interpreted according the ScanExpTime rules, at the
time when the AT command is entered. That implies that if the processing
encounters the command
AT 13:10
at 13:10:01, the command returns immediately, because ScanExpTime
adds the missing part of the full date-time spec from the _current_ time.
This behaviour is different from what was in use in EROS II, where the
processing would have been suspended until the 13:10:00 the next day.
-> If no experiment is active at the time of the command, the command is
silently ignored.
-> <time spec> is silently rounded to nearest millisecond.
Examples
AT "3-Feb-2016 04:05:06.789"
AT 13:10:20
AT fs+1.5s
See also
at ScanExpTime SYNC
azellog --
Log antenna azimuth and elevation to file with high time resolution.
Synopsis
azellog on|off|status
azellog -threshold ?<value>?
azellog -file
azellog -verbose ?<value>?
Description
-> The EROS Monitor process frequently updates antenna azimuth and
elevation information in memory. This command can used to write the
same high-time-resolution information to a file also. The filename is
defined in the EROS boot_config database entry "azellog", and may
contain "DATE" so that the file names will be timestamp-based daily
files. Use the command
azellog -file
to show the current log file name.
-> Logging is enabled/disabled by the command
azellog on/off.
-> The current status can be queried by
azellog status.
-> A threshold value for the position change (either in az or el)
needed before a new value is written to the log can be set by
azellog -threshold <value in degrees>.
-> Current threshold value can be queried by
azellog -threshold.
BLOCK --
Define a subroutine in an elan file.
Synopsis
BLOCK <Name> <Argument list> <Body>
Description
-> The BLOCK command adds some entry and exit code to the standard Tcl
procedure construct (the "proc" command), to allow the routine to be
invoked via the gotoblock and callblock commands, and to allow
EROS to do some bookkeeping and cleanup.
-> The <Argument list> is a normal Tcl proc argument list, and can
specify both obligatory and optional arguments.
-> Otherwise, the BLOCK is a normal Tcl subroutine, with local
variables, etc.
-> The runexperiment command clears all currently defined BLOCKs from
EROS, so that only the BLOCKs defined in the current elan file are
available. They stay available until the next runexperiment command.
-> To get info about currently defined BLOCKs, use the command
block info
-> The special block name main or MAIN provides a BLOCK that EROS
calls automatically at runexperiment, without an explicit
callblock needed, or allowed, in the elan file.
Examples
A minimal elan file could have the following BLOCK structure
----Begin minimal.elan----
MAIN { Par1 args } {
SYNC -10
DISP -hms. "Main entered with arguments $Par1 and $args"
SYNC 10
callblock Scan1 $Par1
}
BLOCK Sub1 { A } } {
DISP -hms. "Sub1 called with A=$A"
}
BLOCK Scan1 { args } {
DISP -hms. "Scan1 entered with $args"
set N 1
DO forever {
DISP -hms. "Scan1: loop $N"
incr N
SYNC 15
}
}
BLOCK Scan2 { {H 295} } {
DISP -hms. "Scan2 entered with H=$H"
set M 1
DO forever {
DISP -hms. "Scan2: loop $M"
incr M
SYNC 10
}
}
----End minimal.elan----
** When the runexperiment command is given, EROS sources the minimal.elan
script, and then automatically calls the MAIN block. Then the
callblock Scan1 in the MAIN moves execution to the BLOCK Scan1,
which contains an infinite loop, thus the call never returns to MAIN.
** At some later time, an operator could invoke the BLOCK Sub1
interactively, using
callblock Sub1 B
Because Sub1 does not contain any SYNC, it would return immediately.
The effect would be essentially the same as when giving interactively
any normal command, so Scan1 would still continue its own execution
without perceptiple interruption.
** If an experiment containing SYNC commands is running, one normally
should avoid making an interactive callblock to a BLOCK that also
contains SYNC commands, especially if the precise timing is
important.
*** For the curious: An interactive callblock is first put to the
Tcl event queue in the same EROS process (the Elan process) where
the original BLOCK is executing, and starts executing when the
original BLOCK yields control to the event loop by entering a
SYNC. If the original BLOCK is already in a SYNC when the
callblock happens (as it mostly normally is), the new block
starts executing immediately. When it then enters its own SYNC,
the original SYNC is pushed down in the common SYNC stack.
This "freezes" it, so that it will not be able to complete its
execution, even if it would normally time out, before it is again
at the top of the SYNC stack. Taking into account that the
termination condition of a SYNC involves comparing UTC agains the
experiment time counter (the "continue_at" time), and each and
every SYNC manipulates that counter, it can be appreciated that
things can become a bit messy.
** To transfer from Scan1 to Scan2 interactively, the operator can use a
command like
gotoblock Scan2 12:13:20 298
This is safe, for the gotoblock terminates the executing BLOCK
before moving to the new BLOCK.
** What would happen if the operator gives a gotoblock to a block like
BLOCK Sub1 that does not contain an infinite loop? The command
terminates the currently executing BLOCK, so EROS cannot return there
anymore. And the BLOCK Sub1 finishes very fast. Where should the
thread of execution go then? Early EROS implementations considered that
situation an error, and terminated (or tried to terminate) the
experiment. No more so. The current EROS implementation is that nothing
particular happens. Internally, Tcl interpreter returns to the script
level, but EROS system considers that a legal event, and
printexperiment still shows the experiment being in the BLOCK
Scan1. No elan file processing is taking place, but so what? It is
still possible to give gotoblock and callblock commands in a normal
way. With this implementation, it is perfectly legal for an experiment
formally "fall through" the end of a BLOCK. EROS still considers the
program to be in that BLOCK, even though no new commands are being
processed. In this situation, the printexperiment command currently
shows the "continue_at" time as empty ("Inf" might be a more
eye-catching indicator), and that is pretty much the only visible
indication of this situation. Note that with this implementation, the
only way to stop an experiment, apart from actual errors, is to give an
explicit stopexperiment command. This can also be placed in an elan
file.
See also
block callblock gotoblock SYNC
block
Manage BLOCKs.
Synopsis
block <ID> <Arglist> <Body>
block info ?<Pattern>?
block clear ?<Pattern>?
block name ?<Pattern>?
Description
-> The command block is used to create, inspect and delete BLOCKs,
which are slightly enhanced Tcl subroutines, procs.
-> In the 3-argument form, block as a synonym for BLOCK, and
is used to create a BLOCK.
-> block info is used to display various info
about BLOCKs matching the <Pattern>. Default <Pattern> is "*".
-> block clear removes the matching BLOCKs from EROS.
-> block name returns full name of each matching BLOCK.
See also
BLOCK
call --
Make a subroutine-call-like invocation of an ELAN file BLOCK.
Alias for callblock
callblock --
Make a subroutine-call-like invocation of an ELAN file BLOCK.
Synopsis
callblock <block name> ?<arg> ...?
call
Description
-> Use callblock mostly in ELAN files. When used within an ELAN file,
callblock is essentially equivalent to execution of a command of
name <block name> in the EROS Elan process. The advantage of using
BLOCKs to define new commands in ELAN file, instead of using the
standard Tcl proc to define them, is that some extra bookkeeping is
done which allows printexperiment to show what block is executing.
Also, BLOCKs do not "pollute" the EROS Elan process name space with
command names, for all existing BLOCKs are deleted as a first step
when a new experiment is started (but not when an experiment is
stopped).
-> When an ELAN file is sourced by runexperiment, all the BLOCKs
defined in the file become known to EROS, and can be called also
interactively from the EROS Console. However, there are caveats in
doing so, as detailed below.
-> If used interactively, callblock is done "in the background", by
using the an asynchronous IPC command (aSend) to deliver the command
for execution to the Elan process. Therefore, an interactive
callblock always returns immediately, even if the called BLOCK
would contain an infinite loop. A corollary is that an interactive
callblock never returns anything to to caller, especially no
indication of any errors.
-> Especially be careful when using callblock interactively if an
experiment is running and the BLOCK to be called yields to the
event loop (explicitly via SYNC or AT, or implicitly via many IPC
calls). It might happen that the thread of execution is
inadvertently given also to the called BLOCK. Mostly, this is not
a problem, but see the next item.
-> Note that a callblock, interactive or not, does not terminate the
calling BLOCK. Depending on the interactively called BLOCK,
typically the execution of the BLOCK that was executing at the
time of the callblock will appear suspended similarly as in the
non-interactive case and will only continue after the called BLOCK
finishes. This probably is the desired behaviour, and is what
normally happens, but EROS does not guarantee that for an
interactive callblock.
If an actual, permanent termination of the executing BLOCK is
required, use gotoblock.
-> Note that a callblock, interactive or not, does not per see touch
the experiment time counters (though any SYNC and AT in the called
BLOCK will of course do that). If such manipulation is required, use
gotoblock.
See also
BLOCK gotoblock gto
cd --
Change working directory in all EROS processes.
Synopsis
cd ? <dir path> ?
Description
-> The cd command tries to change the working directory of _all_
EROS processes to the directory <dir path>. This may succeed
in some processes and fail in others. An error is reported only
if the command fails in the EROS Messages process.
-> The command is implemented using the standard Tcl cd command,
so changes the directory in all threads and interpreters in the
process.
-> Without argument, changes to EROS experiment directory, as defined
in boot_config, the key "erosexp".
See also
ls pwd
celdirection --
Get azimuth and elevation of a celestial object at the local site.
Synopsis
celdirection <name> ?<RA> <declination>? ?<time>? ?<OPTIONS>?
Description
-> If <RA> and <declination> are not given, <name> must refer to a
known celestial object. Known Names are defined in the file
eros/lib/celestial_sources.tcl and can be listed by the command
celsource.
-> If <RA> and <declination> are given, a <name> is still
obligatory, but is not used.
-> <RA> as {hh mm ss.ddd} for epoch 2000.0
<declination> as {degr ' "} for epoch 2000.0
-> With the option "-all", the command returns a five-element list,
containing
azim, elev, sideral time, current RA, current Decl
By default, the units are degr, degr, hours, hours, degr.
-> With the option "-hms" or "-sexa", the return values are in
sexadecimal format.
-> The "planet" positions are computed by calling an external
astronomical program, then "ephem" program, which at EISCAT sites
is available as /kst/bin/ephem. The fixed sources are computed
internally in EROS.
Examples
celdirection cas-a
celdirection moon 23:30
celdirection * {23 23 28} {58 49 14}
celdirection sun -all -hms "Dec 21 12:00:00 2006"
See also
celsource planetinfo pointcelestial
celsource --
Return J2000 RA and Declination of a named celestial source.
Synopsis
celsource ?-name? ?<Pattern>?
Description
-> For fixed-position sources, celsource returns RA and Decl of the
source whos name matches the Pattern in the list of celestial
sources. The RA and Decl are returned in sexadecimal, as 3-element
lists, e.g. {17 20 29.5} and {0 -58 52}. The RA and Decl refer to
the epoch J2000.0.
-> For the nine planets, the moon and the sun, celsource returns
RA={-1 0 0 } and Decl={ -1 0 0 }. Use the command planetinfo to get
RA and Decl of the date.
-> If the flag "-name" is given, only the full names of the matching
sources are returned. The return list is empty if there is no match,
but no error is reported.
-> If the flag "-name" is not given and the match is not unique, an
error is reported.
-> Calling celsource with no arguments is equivalent to
celsource -name *",
that is, a list of all known source names is returned.
-> The sources are defined in the table CelestialSource in
eros<version>/lib/celestial_sources.tcl. This is global table and can be
used in ELAN files if desired.
Examples
celsource cas-a
celsource jup*
celsource -name 3c*
celsource
changedatasource
Switch data source (mainly intented for use at ESR).
Synopsis
changedatasource <antenna name> prog<N> ?<delay sec>?
Description
-> This commmand is mainly intented for ESR, where data source
switching between 32m and 42m antennas requires two things, which
need to happen at two different times, falling on different sides of
an integration period boundary. First, R/C program must be changed
precisely at the boundary, to get transmission re-routed to another
antenna starting from the boundary. The program is changed by
changing the R/C start address before to boundary using armradar,
so that when the R/C restarts at the boundary, it will start using
the new address. Second, the recorder program must be told, after
the boundary, that the data now being collected comes from the new
antenna and therefore requires new file names. This change is done
by using
rtpoke dsp source.
-> <antenna name> is 32m|42m|uhf|vhf|sod|kir
-> prog<N> is R/C program start address identifier, which normally is
defined in the loadradar command, for both radar controllers. The
command loads immediately the start address of that program to R/C
start address register. The R/C will start executing the new program
in next restart (next integration period boundary).
-> <delay sec> is time in fractional seconds to wait before poking the
<antenna name> to the RT-common. The actual value into RTcommon is
antenna number which is 1 for 32m antenna and 2 for 42m antenna. The
current value can be checked by using rtpeek dsp. NOTE that <delay
sec> must be greater than 0.1s, otherwise <antenna name> is not
changed in the RTcommon at all. Therefore, set <delay sec> to zero
if you want to change the R/C program but not the <antenna name>.
-> The R/C program change takes effect at next integration period
boundary. The <delay sec> should be set so large that the <antenna
name> will be changed a little _after_ that boundary, so that data
recorder can use it for file names etc when it prepares the dump at
the end of the integration period. Often it is convenient to set
<delay sec> equal to the integration period.
Examples
Assume a 5 second integration period. Then, about 3 sec _before_ an
IPER boundary, we might give the command:
changedatasource 42m prog2 5.0
Then both R/Cs will start executing program prog2 at that
boundary, and the antenna name will be changed to 42m at about
2 sec after the boundary, and thus should be appropriate for that
integration.
See also
armradar
changelsite --
Change local site for the pointing commands.
Synopsis
changelsite <Site>
Description
-> <Site> must be one of K L|E S T.
-> This command is only allowed under EROS simulator. Pointing variables
are updated via a pointrrange command.
changemode --
Connect to the physical antenna, or change antenna simulation mode.
Synopsis
changemode 0|1|2
changemode rt|simu|geom
Description
-> This command is meaningful only when EROS is run in simulation mode.
Then it is possible to switch between antenna simulation mode where
antenna is simulated and has roughly the correct speed, and antenna
geometry mode, where the simulation antenna's speed is taken to be
infinite. If EROS is started in realtime mode, this command is used
by EROS at boottime, but is ignored thereafter. If EROS is started as
simulator, it is not allowed to change mode to RT access. In all
cases, the command is ignored from inside ELAN files.
0|rt = Access the physical antenna.
1|simu = Antenna simulation mode.
Use a simulated antenna of realistic speed
2|geom = Antenna geometry mode.
Use a simulated antenna of infinite speed
-> Note that EROS on VHF, whether in RT or simulation, is always run
using the simulation antenna. So pointing commands can be given, but
the affect only a simulated (UHF-) antenna.
-> The header of the printantenna command shows the current mode.
changersite --
Change the reference site of pointing commands.
Synopsis
changersite K|S|T|(L|E)
changersite
Description
-> The reference site is required for the two tri-static
pointing commands pointrheight and pointrrange
which have Azimuth and Elevation among their inputs.
The Azimuth and Elevation mean directions at the reference
site. Typically, in UHF system, the reference site is
Tromso (T).
-> With an argument, change current reference site; without
arguments, return current reference site.
See also
pointrheight pointrrange printantenna
checkpolariser --
Verify current polariset setting.
Synopsis
checkpolariser
Description
Verify the correctness of current polariser setting against
current tristatic pointing.
See also
setpolariser printantenna
consolemessage --
Print a message to EROS console window.
Synopsis
consolemessage ?-alarm? Message
Description
-> The console command can be used in an ELAN file to print a
message to the EROS console window. It can also be used in a
remote command, but only in __exceptionally urgent__ cases,
to try to grab the attention of the operator at the remote
site.
kir consolemes "Please, call sodankyla site control room."
-> The flag ?-alarm? tries to make the console message even
more irritating.
See also
message, DISP
correlator --
Manage the lag profile computing Unix program lag_wrap.
Synopsis
correlator ?-ion|-pla? <filfile>|stop|pid
Description
The correlator command is a wrapper for the Unix command-line program lag_wrap.
Normally, the correlator command is invoked via the startdata and
stopdata EROS commands.
See also
startdata stopdata
debug --
Set and query EROS debug level.
Synopsis
debug ?<process>? ?<trace level>? ?logon | logoff?
Description
-> The debug command controls the amount of trace/debug information
printed in the EROS windows.
-> <process> = any of the EROS process names (console, messages, vme,
ioncorrelator, etc), or "all". <level> = 0|1|2|3|on|off
-> logon|logoff turns on|off trace logging to a file.
dec2sexa --
Convert from decimal notation to sexadecimal notation.
Synopsis
dec2sexa DecSpec ?NegInFront?
Examples
dec2sexa -3.75472222 ==> -3 45 17.0
dec2sexa -0.5 => 0 -30 0.0
dec2sexa -0.5 1 ==> -0 30 0.0
dec2sexa 2.19999215 ==> 2 11 60.0 (!!!!)
See also
sexa2dec hms
25-Nov-2010 Jm: Added option esrfmt, so that instead of returning
{0 -58 1.1} we return {-0 58 1.1} This is needed,
for tracking at ESR, where, contrary to antenna manual,
a declination -58' needs to be input not as a string
"0 -58 0" but as "-0 58 0".
definesweep --
Define an antenna sweep past a celestial point.
Synopsis
definesweep Obj Ax Dir t2 Size Speed dt Uncor
Description
-> Return a summary of sweep path and time.
-> Parameters:
Obj: Source name
Ax: "Az" or "El", default = "Az".
Dir: "+" or "-" or 1 or -1, default ="+".
t2: Required time instant for the center of the sweep,
default = "asap".
Size: Required initial angular offset from the source
(degrees), default = 2.0.
Speed: Required speed on the sweep axis, degr/sec. The
angular speed on the sky will be Speed for
elevation scan, and Speed*cos(El) for azimuth
scan.
dt: Time between successive pointings (milliseconds),
default = 200.
Uncor: Flag, if set, do not use current offset model in
pointing, default = 0.
See also
sweepcelestial
DHMS --
Format time as DD-MON HH:MM:SS
See
HMS timestamp
disablerecording --
Prevent the recorder from writing dumps to permanent data area.
Synopsis
disablerecording ?ion|pla|all?
Description
-> The receiver selector switch has effect only on ESR. At the other
sites, flag ion is ignored, and if pla is used, the whole
disablerecording command is ignored. At ESR, without any switch, the
default is ion. Remember to use "all" if both ion and pla are
desired.
-> When the recorder program decodump is running, it will write data
either to a "ring buffer" of 5 files, or to the actual data area.
The disablerecording commands causes the former alternative to be
used (so that the data can still be monitored, even though it is
being quickly overwritten).
-> The disablerecording command is communicated to the appropriate
recorder process by setting a flag in the RT-common shared memory,
where it is transferred to the recorder when the correlator
program sends data to the server at the end of an integration period.
See also
enablerecording recorder
DISP --
Display a message in EROS Elan window.
Synopsis
DISP ?-nonewline|-nonl? ?<message>|<time string>|<Ctrl> ...?
Description
-> This command is used to send a message from an elan file to
the EROS elan window.
The <message>, <time string> and <Ctrl> pieces are all
appended to a single string (without spaces; spaces if required
must be provided explicitly using quotes), and printed to the
EROS Elan window.
-> The following formating strings are recognized separately and
expanded into a time-stamp string:
-t is replaced by "Month-Day hh:mm:ss "
-hms. is replaced by "hh:mm:ss.d "
-hms3 is replaced by "hh:mm:ss.ddd "
-dhms is replaced by "Month-Day hh:mm:ss "
-dhms. is replaced by "Month-Day hh:mm:ss.d "
-dhms3 is replaced by "Month-Day hh:mm:ss.ddd "
Note the extra space at the end of the time string.
Another way is to use explicit time-stamp commands like HMS in
the string.
-> Normal ascii terminal control characters like
\r => move cursor to the beginning of the line
\n => move cursor to beginning of next line
\b => move cursor one character backwards
\t => move cursor to next tab stop
-> In additon, two options, formally of the above char format but
now actually of course two char strings, are supported:
\u ==> cursor up one line
\d ==> cursor down one line
can also be used.
-> The following options emit the appropriate xterm color
control codes to the output string.
-r ==> red
-b ==> blue
-c ==> cyan
-w ==> white
-y ==> yellow
-m ==> magenta
-g ==> green
-B ==> bold
-! ==> reset to normal text
A final terminating -! can be omitted; it is inserted implicitly if
needed so that the formatting does not extend beyond the DISP
command.
Examples
DISP -hms. "This is a test message"
DISP -y "[HMS] " -r -B "This is an error message !"
DO --
Emulate EROS II DO loop
Synopsis
DO <Nloops> <Body>
Description
-> The DO command is the EROS loop-command of choise. It is possible
to use the standard Tcl while- and do-loops, but the DO
command does some extra bookkeeping and allows "skipping",
and is therefore much preferred.
-> <Nloops> is the number of times the <Body> should be executed.
For intinite loop, use <Nloops> = -1 or <Nloops> = "forever".
Examples
DO -1 {
..commands..
}
DO forever {
..commands..
}
DO 100 {
..commands..
}
DYHMS --
Format time as DD-MON-YYYY HH:MM:SS
See
HMS timestamp
e --
Send a command to the ESR EROS.
Alias for esr
edit --
Open file in a text editor.
Synopsis
edit ?<file name>?
Description
The editor to be invoked is defined in the EROS boot_config file.
eDump --
Return, as a multiline string, the EROS configuration database.
Synopsis
eDump ?Radarlist?
Examples
eDump ==> Dump database relevant for current radar
eDump S ==> ... for SOD
eDump * ==> The whole database
eGet --
Return a value from the EROS configuration/state info database.
Synopsis
eGet <item name>
Description
-> Much of EROS configuration data derives from the hand-made file
boot_config.tcl (and simu_boot_config.tcl). This file is
read during EROS boot time by all EROS processes, and the data
moved to internal global array. eGet provides a functional
interface to that array. The command is mainly intended for
internal EROS use, but there should be no harm to use eGet
or eDump to have a peek.
-> During EROS runtime, various state information gets added to
the database, so that the database lives during runtime, and
is different for different EROS processes.
-> The command eDump in the appropriate EROS window can be
used to print out the whole eGet database for that process.
emake --
Update a running EROS from current sources.
Synopsis
emake ?-test?
Description
Check if any of the EROS *.tcl source files is newer than
the mod time of EROS lock file. Then patch all those files
to all EROS Processes. Finally, update the modification
time of the lock. Return a list of the patched files.
With the -test option, only the list of files to be patched
is returned, and no actual patching is done.
This command is mainly intended for EROS developer use.
See also
patch
enablerecording --
Allow the recorder to write data dumps to permanent data area.
Synopsis
enablerecording ?ion|pla|all?
Description
The receiver selector switch has effect only on ESR. At
the other sites, flag ion is ignored, and if pla is used,
the whole enablerecording command is ignored. At ESR,
without any switch, the default is ion. Use the switch
"all" if both ion and pla are desired at ESR.
See also
disablerecording
eq2gal --
Equatorial to galactic coordinate transformation.
Synopsis
eq2gal ?-dec? RA Decl
Description
Equatorial to galactic coordinates.
-> RA as {hour min sec}
Decl as {degr arcmin arcsec}
==>
Lon in sexadecimal {degr arcmin arcsec}
Lat in sexadecimal {degr arcmin arcsec}
-> If the flag "-dec" is used
RA in decimal hours
Decl in decimal degrees
==>
Lon in decimal degrees
Lat in decimal degrees
See also
gal2eq
eros --
Inspect and control a running EROS system.
Synopsis
eros check ?<process>...?
eros lasterror
eros names
eros ping ?<process>...?
eros quit <process> ?<process>...?
eros restart <process> ?<process>...?
Description
-> EROS system consists of several (Unix-level) processes. Inside EROS, they
have names like "Messages" or "Console". These are the names that are
shown in the title line of the EROS windows. The Messages process is the most
important process. If that process dies, EROS cannot function and cannot
be remotely accessed, and must be (re-)started from UNIX level using
a Unix-level command "eros". The EROS command eros is meant
to be used when at least the Messages process is functional.
-> <process> is one of the EROS process names. The names can be listed using
eros names
Character case is ignored, and the name can be abbreviated from the end.
-> eros check <process>:
This subcommand attempts to connect to the given process or processes, and
indicates whether the connection succeeds ("up") of fails ("down"). In case
of failure, it might be possible to recover the process by restarting it using
-> eros restart <process>:
This kills the indicated <process> and then restarts it.
-> eros ping <process>:
This subcommand tries to execute a simple command in the indicated <process>
and returns a rough estimate of the time required for the whole operation.
-> eros quit <process>:
This subcommand terminates the given process. It should be restarted using
eros restart <process>.
-> eros lasterror:
This command prints out the last error that has happened in the EROS Elan process.
This subcommand is mostly intended for remote inspection; for local use, one
might prefer using the EROS command lasterror which opens the error message
in a text editor.
See also
debug
eDump
ipcmonitor
lasterror
monitor
powermonitor
printcomm
printlog
Query
uptime
version
erosfir --
Return pathname of the standard filter directory.
Synopsis
erosfir
See also
loadfilter
esr --
Send a command to the ESR EROS.
Synopsis
esr ?<arg> ...?
e ?<arg> ...?
Description
The command is shorthand for rradar esr ?<arg> ...?
See also
remote rradar
esrant --
At ESR, send a command to the 32m antenna.
Synopsis
esrant ?<arg> <arg> ...?
Description
-> This wrapper around the Unix-level "acue" commands allows
arbitrary commands to be send to the 32 antenna at ESR.
(Acue is executed by the EROS Messages process.)
-> The command returns an error at the other sites.
Example
esrant Speed-Normal yes
esrant Speed-Set 1.5 yes
esrant Azimuth-Offset 2.5
esrpowermeter --
Access ESR power meters via the tx monitoring computer.
Synopsis
esrpowermeter getpower ?-all?
esrpowermeter info ?-all?
esrpowermeter reconnect
esrpowermeter setduty VALUE
etle --
Manage TLE-based satellite position calculations.
Synopsis
etle init
etle reset
etle sitedef LAT LON ALT ==> SITEHANDLE
etle sitepar SITEHANDLE
etle read FILENAME TAGTYPE TAG ==> TLEHANDLE
etle read2ln LINE1 LINE2 ==> TLEHANDLE
etle par TLEHANDLE
etle free TLEHANDLE
etle celpos TLEHANDLE SITEHANDLE JULIANDATE
etle dir TLEHANDLE SITEHANDLE YEAR MONTH DAY FRACTIONALHOUR
Description
The etle command has been compiled directly to the EROS wishe/tclshe C-code, and facilitates
TLE-based position calculations. In EROS distribution, the source is kept in
eros5/eros<version>/src, in files tlelib.c, tlelib.h, and tmpv.c, which implements the Tcl
interface to the underlying open source C-package copied from
http://www.projectpluto.com/sat_code.htm as it was in October 2010. The sat_code
package consists of about 10 smallish C-files, which EROS uses precisely in their
original form.
Under EROS, it is probably more convenient to use etle via the wrapper tle.
SUBCOMMANDS
-> INIT must be given before any other subcommands to initialize internal data
structures. INIT clears all site definitions and TLE definitions.
-> RESET does not clear site definitions, it only clears TLE definitions. The maximum
number of TLE definitions and site definitions is hard-coded in tlelib.h, currently,
200 and 20, respectively.
-> SITEDEF is used to define observer's location info: Latitude (degr), Longitude
(degr, positive east), and altitude above the reference spheroid, meters.
The command return the SITEHANDLE, which is a string of the form "tsNN".
-> SITEPAR return the site's location in the form of a parname parvalue -list.
-> READ takes name of Norad-format file, such as are available for instance via
the CeleTrak web site http://celestrak.com/, and an object identifier ("TAG"),
seeks and reads the TLE descriptor from the file, and returns a TLEHANDLE, which
is a string of the form "tleKKK". The TAGTYPE determines what kind of TAG the
command looks for, and can be either "c", "i" or "n". C means the "colloquial name,
that is, the name given in "line0" of the TLE specification. I means the
international designator, and "N" means the Norad catalogue number.
-> READ2LN reads the TLE descriptor from the two given strings, which must be
in the standard TLE format. The command returns TLEHANDLE for the descriptor.
-> PAR returns (most) of the TLE descriptor fields as a parname parvalue -list.
-> FREE releases a given TLE descriptor. (RESET releases all of them).
-> CELPOS computes RA and declination at the given site and at the given Julian
(fractional) date. The RA (hours) and DEC (degrees) refer to the epoch J2000.0.
-> DIR computes azimuth (degr), elevation (degr) and range (km) at the given site
and the specified time. The time is given as e.g. 2010 11 16 15.75 (16-November-2010 15:45 UTC).
See also
tle
expid --
Format an experiment ID string.
Synopsis
expid <Expname> <Scan> <Version?Site?> <Owner>
Description
-> Return a properly formatted expriment ID. If the calling process is
Elan (that is, expid is called from an ELAN file), prepend the prefix
"kst0" in front, so that the returned expid can directly be given to the
startdata command.
Example
expid beata cp1 2.0u sw
==> beata_cp1_2.0u_SW
expinfo --
Return various state info about current experiment.
Synopsis
expinfo ?<pattern>...?
expinfo -dict ?<pattern>...>
expinfo -ls ?<pattern>...?
expinfo -names ?<pattern>...?
Description
-> At the moment, the command just returns some or all of the element of
the experiment-related EROS state array mpv(exp,*) as kept in the
Messages process. The <pattern> can be used to select items to
retrieve.
-> With -ls, the return value is a list of values of the matching fields.
This makes sense only if each separate <pattern> has a unique match;
therefore, an error results if this is not the case.
-> With -dict, the return value is a dictionary with the matching fields.
-> With -names, the return value is a sorted list of matching fields names.
-> No <pattern> is equivalent to "*", returning all fields.
-> The default flag is -ls, except when no <pattern> is specified, in which
case the default flag is -dict.
Examples
expinfo -ls *time*
==> returns a list of all item names matching *time*, like
blockstarttime, etc.
expinfo file
==> returns name of current ELAN file
expinfo file starttime
==> returns name of current ELAN file, and the exp start time in Unix
time format.
expinfo -dict
==> returns all experiment state info as a dictionary
expinfo -dict *time*
==> returns all time items of the experiment in a dictionary
expinfo *time*
==> raises an error (ambiguous pattern)
See also
getstarttime
filan --
Compile correlator control (.fil) file.
Synopsis
filan -f <filfile>
Description
The command is a wrapper for the Unix-level "filan" compiler.
The compilation produces a .DECO file, which is required by
the "lag_wrap" correlator program.
Example
filan -f /kst/exp/bella/bella-u.fil
==> /kst/exp/bella/bella-u.DECO
findfile --
Find a file in a hierarchy of files.
Synopsis
findfile ?<Root>? <Pattern>
Description
-> The command is a tailored EROS frontend to the standard
Unix find command.
-> The default root is obtained via [eGet erosexp], and thus
is defined via /boot/boot_config.tcl. Normally, it will be
"/kst/exp".
Examples
findfile tau1.elan
findfile *cp3*
findproc --
Find the file location of an EROS subroutine ("proc").
Synopsis
findproc ?-<editor>? <proc name>
Description
-> The primary purpose is to find source code of EROS commands (both
those visible to the user, and those only used internally).
-> Use Unix grep and find to locate a procedure (proc) among the EROS
source files. By default, .tcl files in the hierarchy starting from
the EROS home directory (such as eros5.8) are looked for. The grep
target is
"proc <proc name> "
in the beginning of a line. This will catch most, but not all,
of the procs.
-> This version does not allow wild cards in <proc name>. Or rather,
they are handled as ordinary characters, so grep will propably fail.
So, the <proc name> must match exactly.
-> The return value is a line giving the file location of the proc,
in terms of source file path name and a line number in the file.
Occasionally, multiple lines can occur, as a proc might be
defined in several files (this is not necessarily an error, EROS
setup might have been directed to select a particular version).
-> If -<editor> flag is NOT used, the output is just
<path name> <line number>
-> If -<editor> is used, with <editor> a supported editor name,
the output is arranged so that it can be directly given to the
editor. In particular, for "-nedit" and -gedit the output is
+<line number> <path name>
for "-subl" the output is
<path name>:<line number>
Example
findproc findproc
==> /kst/eros5/eros5.8/lib/eros_commands.tcl 13202
findproc -nedit findproc
==> +13202 /kst/eros5/eros5.8/lib/eros_commands.tcl
findproc -gedit findproc
==> +13202 /kst/eros5/eros5.8/lib/eros_commands.tcl
findproc -subl findproc
==> /kst/eros5/eros5.8/lib/eros_commands.tcl:13202
See also
[gedit] nedit subl
fullfile --
Return a full file name, as seen by the given EROS process.
Synopsis
fullfile <pattern> ?<process>?
Description
Default process is the Messages process.
gal2eq --
Galactic to equatorial coordinate transformation.
Synopsis
gal2eq ?-dec? Lon Lat
Description
Lon is galactic longitude ("l")
Lat is galactic latitude ("b")
The return value is a two-element list {RA Declination}
If the flag "-dec" is not used, both input and output
is in sexadecimal, that is,
Lon as {degr arcmin arcsec}
Lat as {degr arcmin arcsec}
RA as {hour min sec}
Dec as {degr arcmin arcsec}
If the flag "-dec" is used, both input and output are in
decimal units, that is,
Lon as decimal degrees
Lat as decimal degrees
RA as decimal hours
Dec as decimal degrees
Examples
gal2eq {134 23 45} {-9 12 34}
gal2eq -dec 134.3958 -9.2094
See also
eq2gal
gedit --
Edit files in the "gedit" editor.
Synopsis
gedit <pattern>
gedit +<linenumber> <filename>
Description
The implied files are opened in the gedit editor,
in a single window (multiple tabs).
The command is allowed only on the local EROS console.
geometry --
Start the EISCAT geometry program.
Synopsis
geometry
Description
-> The program is implemented as a set of Matlab commands
in the directory /kst/eros4/geom. The startup script
moves to that directory, launches Matlab and performs
some initializations.
-> The following subcommands are available:
pointrrange Az El R
pointrheight Az El H
pointgeographic Lat Lon H
changersite K|S|T|E
setpolarizer
geom format long|short
geom xsite Lat Lon Alt
geom reset
geom info
geom help
Warning
Do not use geometry as a remote commands, the Matlab window
would open on the remote EROS terminal.
getdirection --
Return current antenna azimuth, elevation and status.
Synopsis
getdirection ?<OPTIONS>?
Description
-> The antenna direction and status are read from the antenna HW.
-> Note that if the returned -status is "fault", any returned
direction parameter can be incorrect without warning.
-> If the antenna status cannot be read at all, an error is raised.
OPTIONS
-acu: With this flag, the returned direction parameters are
directly the HW values.
Without this flag, returned direction parameters are
the true direction values, which are derived from the HW values
by inverting the site's pointing offset model.
-azim, -elev, -status, -ready: If none of these is specified, the default
is as if -azim and -elev would have been specified. If any of these
is specified, then the corresponding parameters are returned
as a list, in the order corresponding to the input order.
-azim: Return azimuth, using the full azim interval, which
is about 90 ... 630 at KST and about -270 ... 270 at ESR,
-elev: Return elevation which is about 0 ... 100 at KST and
about 0 to +180 at ESR.
-stat: Return one of the strings "online", "offline" or "fault"
-ready: Return one of the strings "ready", "moving_a",
"moving_e" or "moving_ae".
-isok, -isready: Return status and ready as boolean value instead
as a string. -isOK returns 1 if there is no "fault",
and isReady returns 1 if both azim and elevation are ready.
-all: This is shorthand for using options -status -ready -azim -elev
Examples (for KST)
getdirection
==> 541.600 77.300
getdirection -stat -ready -a -e
==> online moving_ae 541.600 77.300
getdirection -isready
==> 0
getiperiod --
Return current integration period.
Synopsis
getiperiod ?s|us? ?ion|pla?
Description
-> Return the integration period of current (or latest run) experiment.
-> The value is picked from an EROS internal variable, as set by the
startdata command.
-> At ESR, the data access chain as ion or pla can be specified.
-> The integration period is defined either in microseconds or in
fractional seconds as requested. Default is fractional seconds.
getpolariser --
Find correct polariser settings.
Synopsis
getpolariser ?0|1?
Description
Return optimal polarizer PHA AMP corresponding to the current
tristatic pointing, for the current local site (which must be KIR
or SOD; for all other sites, we return ""). If tristatic
pointing is not defined, we return error.
The setting is returned as a two-element list {PHA AMP}
If the optional flag is not set (0), the appropriate "uncorrected"
polariser settings are returned. Default is to have the flag set (1),
See also
checkpolariser setpolariser
getrepetitionperiod --
Extract various parameters from a radar controller binary file.
Synopsis
getrepetitionperiod <xbin> ?ITEMS?
Description
-> The command is is a wrapper on the Unix-level get_rep command, which
inspects the header of the RC binary.
-> ITEMS:
-rep => Repetition period, fractional microseconds.
-size|-len => Program length in 8-byte RC words.
-rf => RF duty cycle in %.
-beam => Beam duty cycle in %.
-> RF and Beam can only be returned from TX files (.tbin).
Items that are requested but are not found are returned as -1.
-> If no items are explicitly specified, rep is returned.
-> Note that this command presently only works for .xbin files which contain
a single program.
Examples
getrepetitionperiod /kst/exp/tau2pl/*r*.rbin
==> 3571120.0
getrepetitionperiod /kst/exp/tau2pl/*.tbin -rep -beam
==> {3571120.0 11.43}
getrepetitionperiod /kst/exp/tau2pl/*.tbin -rf -beam
==> {10.32 11.43}
getrepetitionperiod /kst/exp/tau2pl/*r*.rbin -rep -rf -beam -size
==> {3571120.0 -1 -1 1511}
getstarttime --
Return latest start time of an EROS device or subsystem.
Synopsis
getstarttime <Device>
Description
The EROS Messages process is consulted. If the required start time
is > 0, it will be returned as seconds, else -1 is returned.
<Device> can be
E experiment start time
B block start time
R receiver radar controller start time
T transmitter radar controller start time
C current value of the "continue at" time counter.
For E, the returned experiment star time is the requested
start time which determines synchronization, not the actual
moment of sourcing the experiment script. Similarly for B.
gotoblock --
Terminate current BLOCK in a running expriment and start a new one.
Synopsis
gotoblock <blockname> <timespec> ?<arg> ...?
gotoblock info|cancel
gto ?-t <timespec>? ?--? <blockname> ?<arg> ...?
gto info|cancel
Description
-> Schedule for the specified time <timespec> start of execution of the
BLOCK <blockname>. If <timespec> is later than current UTC,
gotoblock is scheduled but not executed, else it is executed
immediately.
-> A gotoblock affects a "context switch" which is not too different
from stopping an experiment and starting it in a new BLOCK.
Especially, the switch will always adjust the experiment time counter,
as explained below. Also, irrespective how deeply the experiment was
in nested subroutines, the execution of a new block starts from the
script level.
-> The <arg>s if any are given directly as parameters to the invoked
BLOCK. Their number must correspond to what the called BLOCK expects,
else an error results.
-> When the gotoblock takes place, the EROS experiment time counter is
set to <timespec>. That is, the BTIME ("block time"), as as shown by
printexperiment, is set to <timespec>, and the synchronization time
counter, the "continue_at" time or CTIME, is also set to <timespec>.
Thus, the SYNC commands in the new BLOCK will be relative to the
<timespec>, not relative to the original exp start time ETIME, which
is not changed by a gotoblock command. No memory of any possibly
preempted SYNC from the old BLOCK is carried over to the new BLOCK.
-> To cancel a scheduled but not imminent gotoblock command, use the
command
gotoblock cancel.
Only one gotoblock can be scheduled at any given time. To change a
scheduled but not imminent gotoblock, just give a new gotoblock
command, to the same or to some other block, and it will overwrite the
scheduled one.
-> gotoblock info
returns info about the currently bending gotoblock command.
-> If there is no experiment running, a gotoblock is ignored.
-> The gto version of the command is equivalent to
gotoblock <blockname> now ?<arg> ...?.
If required, a <timespec> can be given explicitly: immediately after the
command predix using -t <timespec>, or at any position using
--t <timespec>.
-> The command can be used both interactively and in ELAN files, though
its use in ELAN files may become depreciated; a callblock should be
used instead of gotoblock in ELAN files whenever possible.
Examples
gotoblock scan2 "17-Aug-2010 14:30:30" 298.5
gto myblock par1 par2 ==> now
gto -t "17-Aug-2010 14:40" myblock mypar1 mypar2
gto -t fm -- myblock -t -v mypar3 ;# "--" is required now
gto myblock -t -v mypar3 --t fm
gto myblock now ==> "now" is given as parameter to myblock
See also
BLOCK callblock
gto --
Transfer execution to a specified BLOCK in current experiment.
See gotoblock
h --
Send a command to the Heating EROS.
See hea
hea --
Send a command to the Heating EROS.
Synopsis
hea ?<arg> ...?
h ?<arg> ...?
Description
The command is a shorthand for rradar hea ?<arg> ...?
See also
remote rradar
help --
Return a help message for an EROS command.
Synopsis
help <command name pattern>
<command name> ?
Description
The <command name pattern> can be abbreviated, and need not to be
unique. If a unique completion is found, information of
the usage of the command is returned.
Examples
help print ==> commands starting with "print"
help *cel* ==> commands containing "cel"
help pointrr ==> help for the pointrrange command
pointrr ? => help for pointrrange command
HMS --
A family of timestamp routines.
Synopsis
HMS ?sec?
HMS. ?sec?
HMS1 ?sec?
HMS3 ?sec?
HMS6 ?sec?
DHMS ?sec?
DHMS. ?sec?
DHMS1 ?sec?
DHMS3 ?sec?
DHMS6 ?sec?
DYHMS ?sec?
DYHMS. ?sec?
DYHMS1 ?sec?
DYHMS3 ?sec?
DYHMS6 ?sec?
Description
-> Value of fractional seconds from 1970.0 is converted
to a string with various output formats.
-> If <sec> is not given, the current sec is picked via Utime, which
gives time with millisec resolution. Therefore, for routines like
HMS6, the time is picked via [clock microsec].
-> HMS ==> HH:MM:SS
HMS1|HMS. ==> HH:MM:SS.f
HMS3 ==> HH:MM:SS.fff
HMS6 ==> HH:MM:SS.ffffff
-> DHMS ==> DD-MON HH:MM:SS
DHMS1|DHMS. ==> DD-MON HH:MM:SS.f
DHMS3 ==> DD-MON HH:MM:SS.fff
HHMS6 ==> DD-MON HH:MM:SS.ffffff
-> DYHMS ==> DD-MON-YYYY HH:MM:SS
DYHMS1|DYHMS. ==> DD-MON-YYYY HH:MM:SS.f
DYHMS3 ==> DD-MON-YYYY HH:MM:SS.fff
DYHMS6 ==> DD-MON-YYYY HH:MM:SS.ffffff
See also
timestamp TimeStamp
hms --
Format a decimal time/position to "hh mm ss.s" notation.
Synopsis
hms Decimal ?separator?
Examples
hms 5.1234 ==> 05 07 24.2
hms 135.5 : ==> 135:30:00.0
See also
dec2sexa
hms_us
Timestamp as hh:mm::ss.microsecs
IDLELOOP --
An infinite do-nothing loop for elan files.
Synopsis
IDLELOOP ?Seconds?
Description
The command is a shorthand for
DO forever {
SYNC -hms ?Seconds?
}
inhibitantenna --
Start ignoring pointing commands on one or both axis.
Synopsis
inhibitantenna ?azimuth? ?elevation? ?clockdelay?
inhibitantenna what
Description
-> Per-axis inhibits are only implemented for U, K and S antennas.
Attempt to specify az, el or clk in other systems gives an error.
-> Without any arguments, antenna motion is inhibited and the
clock delay will not change. This is same as when giving all three
arguments. Only the first letter ("a", "e", "c") of an argument
is significant.
-> With one to three arguments, precisely the given item(s) are inhibited.
For example, if only "azimuth" is given, then azimuth will not change
but elevation and clock delay change normally.
-> Use the command allowantenna do get back to normal, non-inhibited
mode. EROS will not do this automatically except when EROS is
(re-)started. Especially, EROS will not automatically clear inhibit
state when an experiment is stopped or started.
-> inhibitantenna prevents only the AUTOMATIC setting of clock delay
in connection with tristatic pointing commands in KIR and SOD.
Irrespective of the inhibit state, the clock delay can still be set by
an explicit setclockdelay command. Also note that EROS can only set
the clock delay automatically when an experiment integration time
is currently defined in EROS (e.g., when an experiment is running).
-> Use
inhibitantenna what
to query the current inhibit status. The inhibited quantities, if any,
are also indicated by printantenna, and printexperiment.
-> Note that with only one axis inhibited, the tristatic, commanded,
pointing that is shown by printantenna, can be quite inconsistent
with the actual local azimuth and elevation.
-> inhibitantenna affects also pointcelestial and trackcelestial, but
the precise behaviour is neither well defined nor well tested.
Examples
inhibitantenna
inhibitantenna az el clk
==> Pointing commands will have no effect, apart from generating
warning messages.
inhibitantenna az el
==> Antenna will not move after a pointing command, but with
a tri-static command in KIR and SOD, the clock delay is set to
correspond to the common volume implied by the command. Note
that even in this case, the clock delay is set only if
an experiment integration time is known to EROS. Typically,
this requires that an experiment is running. See setclockdelay
for more info.
inhibitantenna az
==> Antenna azimuth will not change by a pointing command, but elevation
is changed normally as implied by the command. After a tri-static
pointing command, the clock delay is set to correspond to the
common volume requested in the tri-static command. Therefore,
with a vertical VHF beam in Tromso, KIR and SOD could inhibit their
azimuth movement and still measure at different altitudes along
the TX beam. Note that the clock delay can be set only if an experiment
integration time is known to EROS.
inhibitantenna clk
==> Both local azimuth and elevation are changed normally, but the clock
delay is not changed automatically with a tristatic pointing command.
Note that pointing info, including PPD, is calculated normally. It is
only the clock delay that is not changed, neither in printantenna
nor in hardware.
inhibitantenna az clk
==> The local azimuth and the clock delay are not changed by a pointing
command, but the local elevation will change as implied by the command.
inhibitantenna what
==> Returns the current inhibit state as a list that shows which of the
three quantities are inhibited (=1), and which are allowed (=0) to
change in pointing commands.
For example, the list
azim 1 elev 0 clockdelay 0
shows that azimuth motion is inhibited, but elevation and clockdelay
are allowed to change by pointing commands.
The inhibit-status is also indicated by the printantenna command.
See also
allowantenna printantenna
ipcmonitor --
Turn ON/OFF interprocess communications monitoring by EROS Monitor process.
Synopsis
ipcmonitor
ipcmonitor on|off
ipcmonitor delete|add <process>
Description
-> EROS Monitor process can be requested to periodically check if it can communicate
with a given set of EROS processes. The original purpose of such monitoring was
to detect if an EROS process had died, and then automatically restart it if required.
-> One use of the automatic restart feature is to clear a "hanging" EROS console window.
Such apparent freesing can result for instance from a remote command when the remote
site is not responding properly for the defalt timeout is several minutes. If the
automatic restart via the ipcmonitor is enabled, one just kills the window using
the windoc control button, and in a few seconds, the window will pop up again,
will communications cleared.
-> The default set of processess to monitor is defined in the EROS boot_config.tcl
file via the entry "commchecklist", but processes can be added or removed
on per EROS session bases using ipcmonitor delete or ipcmonitor add.
isnan --
Test if a thing is NaN.
Synopis
isnan x
Description
Return 1 if x is a valid IEEE number, return 0 otherwise.
This is basically for the cases that tcl's built-in
"string is" -command cannot handle correctly, such as
when a NaN value has been is explicitly assigned for a numerical
entity.
isradar --
Check if the local radar is one of the given radars, or query the name
of current radar.
Synopsis
isradar ? <radar list> ?
Description
-> Without <radar list>, return the current radar system name, as e.g
"UHF", or "ESR".
-> The main purpose of the command is to allow experiment files to do
things depending on in which system the file is executing.
-> With <radarlist>, return true (1), if current radar is any of the
radars in the list, return false (0) otherwise.
-> The <radarlist> can be given either as a string consisting of
single-letter system IDs, such as "U" or "E", or as separate
three-letter radar names, see the example below.
Examples
Assume we are running at UHF. Then
isradar ==> "uhf"
isradar uhf ==> 1
isradar u ==> 1
isradar kir sod ==> 0
isradar ksu ==> 1
See also
ISUHF ISVHF ISSOD ISKIR ISESR
istracking --
Return antenna celestial tracking on/off state.
Synopsis
istracking
Description
Return 1 if celestial tracking is going on, else return 0.
ISUHF --
Return 1 if current radar is UHF, else return 0.
Synopsis
ISUHF
Description
The command is shorthand for isradar uhf.
See also
isradar ISVHF ISSOD ISKIR ISESR ISTRO
k --
Send a command to the Kiruna EROS.
See kir
kir --
Send a command to the Kiruna EROS.
Synopsis
kir ?<arg> ...?
k ?<arg> ...?
Description
The command is a shorthand for rradar kir ?<arg> ...?
See also
remote rradar
lasterror --
Show latest EROS error traceback.
Synopsis
lasterror ? -EDITOR ?
Description
Open the EROS last error file in an editor.
This command is only available on the local console.
-EDITOR = -vi | -subl | -nedit
If EDITOR is not specified, the EROS default editor is used.
loadexciter --
At ESR, load frecuency table from file to the exiter.
Synopsis
loadexiter Filename
loadfile --
Source a Tcl code file in the EROS Elan process.
Synopsis
loadfile <file name>
Description
This command is mainly intented for use in ELAN files. It causes the
file <file name> to be sourced in the EROS Elan process, which is the
process executing the ELAN files. Note that the command _may_ be
dangerous. If the file does not return fast, EROS probably will hang.
The file should only contain simple commands, or proc definitions. It
is possible also to use just the plain Tcl "source" command, but
loadfile does some extra bookkeeping.
See also
patch
loadfilter --
Load filter definition from file to receiver channel(s).
Synopsis
loadfilter ?<receiver>? <filter file> <channels> ?<OPTIONS>?
Description
-> Download filter and decimation control parameters from a file to the
HSP43220 chips on a receiver channel board. These parameters
determine the post detection filter shape and the final sampling
rate (by defining decimation factor).
-> loadfilter is equivalent to loadfilter ion.
-> loadfilter pla is ignored at non-ESR sites.
-> The file is checked, and unless the -T option is used, the
parameters are loaded to the specified channel board. An example of
a minimal firpar file is shown below (character case is not
significant).
---------------------------------------------------------------
FIRPAR_VS 0.1 % this must be the first
% non-comment line
%==========================
% test.fir
%==========================
F_TAPS 8 % 9 coefficients in FIR
F_DRATE 9 % FIR decimation 10
H_STAGES 3
H_DRATE 39 % HDF decimation 40
TAP 0 0x019E4 % h0 = h8
TAP 1 0x06790 % h1 = h7
TAP 2 0x102E8 % h2 = h6
TAP 3 0x19E41 % h3 = h5
TAP 4 0x1EBED % h4
---------------------------------------------------------------
The tap values are specified to the hardware in 2's complement
1+19bit fractional format, and can be typed in either as 20 bit hexa
or 1+19 bit signed integer form. Note that ALL numeric values are
read in assuming C-language integer conventions. Thus for example
"TAP 08 -123" is illegal because "8" is not an octal number.
-> A collection of predefined filter files is in the directories
/kst/dsp/fir and /kst/fir.
-> More filters can be designed by the Matlab scripts
/kst/dsp/fir/ddf/ddf10.m and /kst/dsp/fir/ddf/ddf15.m
Examples
loadfilter /kst/dsp/fir/b14d375.fir ch1,2
loadfilter pla /kst/dsp/fir/b800d6.fir ch1,2,3,4,5,6
loadfrequency --
Load a set of frequency value from file to a channel's memory.
Synopsis
loadfrequency ?<OPTIONS>? <channel list> <frequency file>
loadfrequency ?<OPTIONS>? ?<receiver>? <channel list> <frequency file>
Description
-> The loadfrequency command checks the syntax of the <frequency file>
for the channel's numerically controlled oscillator (NCO), and loads
the frequency value table to the channel memory.
-> <receiver> selector has effect only at ESR, where it can be either
"ion" or "pla", for the ionline and plasmaline receiver,
respectively. If the selector is omitted, "ion" is used.
-> <channel list> is a string of channel identifiers. For example
ch1
ch1,3
ch1 ch3
-> Extension ".nco" is required in the <frequency file>. In ELAN
files, absolute path names should be used for the file names.
-> OPTIONS
-v: Verbose loading, showing the load table with 0.1 mHz
freq accuracy.
-T|-test: No actual loading, but file syntax is checked.
-E: Enforce ESR exciter-compatible frequencies.
This is the default behaviour at ESR. The ESR exciter
has four times coarser frequency granularity than
the NCO, and this options forces the given NCO
frequency to the nearest available exciter frequency.
-u|-uncorrected: Enforce NCO-native frequencies.
From Summer 2015, this is the default behaviour at
non-ESR sites.
-> The structure of a NCO frequency file is the following:
--------------------------------------------------------
NCOPARS_VS 0.1
NCO 1 10.1 % Mem address 1 contains 10.1 MHz
NCO 2 9.8 % Mem address 2 contains 9.8 MHz
... ... % etc
--------------------------------------------------------
-> Use NCOSEL1 and NCOSEL2 in the .tlan file to trigger
these values into use.
Examples
loadfrequency ch1_tau1.nco ch1
loadfrequency freq2.nco ch1,2
loadfrequency pla ch2_tau0.nco ch2
See also
setfrequency
loadradar --
Load radar controller program and/or RC registers.
Synopsis
loadradar <RCNAME> ?OPTIONS?
Description
-> This command is mainly intended for loading the RC program to the RC
memory, but can also be used to load the RC registers, (the start
address register, the loop counter register, and the sync count
register). The RC needs to be in the "stopped" state when the program
is loaded, but the registers can be loaded at any time.
-> If there is only one RC program in an experiment, it is natural to
load both the program and the registers at the same time. If there
are multiple programs (which may or may not be in a single XBIN
file), one needs to decide when to load the registers. Either all
register loading is done "late", just before the RC is started or
restarted, or the registers are initialized at the program load-time
with the parameters of the first needed program.
-> Note that also the armradar command is (nowadays) capable of
loading the RC registers. One benefit of always using armradar for
register loading is that then one can use symbolic program names of
the form prog<N> to refer to the program start address. The mapping
from prog<N> to the address is defined via the loadradar command.
OPTIONS
-f <XBIN> ?-prog<N> <ADDR>|-A <ADDR>|-a <ADDR>?
-prog<N> <ADDR>
-a <ADDR>
-l <LOOPCOUNT>
-s <SYNCCOUNT>
-> Each of the options can occur at most once (per command).
-> <RCNAME> specifies the target radar controller, either a transmitter
RC (tra) or a receiver RC (rec|ion|pla).
-> The program in <XBIN> is loaded to address <ADDR> in the RC memory. The
RC must be in "stopped" state for this to be possible. If more than one
program is defined in the <XBIN> file, all of them are loaded into
consecutive locations, starting from <ADDR>. (With multiple programs
in a single <XBIN> file, it may be less confusing to use -A <ADDR> or
-a <ADDR> than -prog<N> <ADDR> to specify the load address, but this is
not enforced.) If -f <XBIN> is used but none of the three load address
specifications is present, the program is loaded to the address 0, as
if -A 0 were given. Note that this is changed behaviour: before Jun
2008, when -f XBIN was used, a zero was always poked to the SA
register, too. <ADDR> is in terms of the 8-byte RC words and counts
from zero. The RC memory size is 256 k RC words.
-> The difference between -A <ADDR> and -a <ADDR> is that -a <ADDR> also
loads <ADDR> to the start address register. When the form -prog<N> <ADDR>
is used to specify the load address, the start address register is not
touched unless -a <ADDR> is also used.
-> If the address is specified as -prog<N> <ADDR>, the ID "-prog<N>" can
later be used to refer to <ADDR> in the armradar command. To specify
symbolic start addresses in the case when the <XBIN> contains multiple
programs, use multiple loadradar commands, all but one without
specifying the -f <XBIN>, e.g.
loadradar tra -prog2 789 ".
The SA must have been found from the TARLAN compiler output.
-> Note1. In ELAN files, absolute path name should be used for <XBIN>.
-> Note2. With -f <XBIN>, in the present implementation, when the target RC
is a transmitter RC, the "RF duty cycle" is picked from the <XBIN>
header, and is written to the EROS shared memory.
-> The switches -a, -l, and -s control RC register loading. There are no
default values, so if an option is not specified, no register loading is
done. <SA> is a start address, <LC> is number of RC loops in the integration
period (LC-1 is actually loaded to the register), and <SC> is the synch
count at the end of the RC program before the next restart, in terms of
100 ns intervals, see below (If SC>0, SC-1 is loaded to the sync count
register; if SC = 0, zero is loaded).
-> The loopcounter and the R/C program loop duration (the "REP" time)
determine the integration period IPER, IPER = ceil(LC * REP), where "ceil"
here means rounding up to nearest full 10 millisecs. In fact, EROS assumes
that IPER actually is a multiple of 100 millisec, so <LC> and REP should be
chosen accordingly. Confusion results if this rule is not respected. <SC>
should be set to (IPER - LC*REP)/100 ns. For example, if REP=714240us and
LC=7, REP*LC=4999680us, [REP*LC]=50000000us, and so <SC> must be set to
3200. The command radarloops can be used to compute the <LC> and <SC>
values. The command getrepetitionperiod can be used to read the REP from
a RC binary file.
-> (This section courtesy to Arild S.). The case of loopcounter value unity needs
special attention when switching R/C programs by changing start address on
the fly (either using loadradar or armradar).
** Normally when one changes SA in the fly, the RC will load the new value
to the address generator register (AGR) when the last loop starts, so it
will start with the new address at next sync pulse after the last loop.
** In the case of LC=1 one is always in the last loop. That means SA will be
loaded in every loop. When one changes SA on the fly in this case, it
will be loaded to AGR at the start of next loop and the RC will start
with the new address in the loop after that. If the new program has a
different REP one is in trouble with the sync error counter for one
loop, since the error counter is loaded for every new scan. One has to
take that into account.
** Running multiple programs with LC=1 and wants to change on the fly it
is recommended that the programs have the same rep rate.
** Changing from LC=1 to LC>1 on the fly is not recommended.
Examples
loadradar rec -l 14 -s 0 -prog1 0 -f xxx.rbin
Load program(s) from xxx.rbin to RC address 0, and in addition, load 13 to
loop counter register, load 0 to sync counter register, and associate address
0 to name "prog1" for armradar rec. Update radarinfo of RX prog_1 LC, SC,
SA, LA, and fil. Note that the start address register is not loaded by this
command, see the next example.
loadradar rec -l 14 -s 0 -a 0 -prog1 0 -f xxx.rbin
All of from previous example, and in addition, zero is loaded to the SA register.
loadradar tra -f xxx.tbin
Load program(s) from xxx.tbin to RC location 0. Registers are not touched.
loadradar rec -prog2 1000 -f xxx2.rbin
Load program(s) from xxx2.rbin to RC location 1000, Associate addr to the
name prog2 for armradar rec. Registers are not touched.
loadradar rec -A 1000 -f xxx2.rbin
Load program(s) from xxx2.rbin to RC location 1000,
Registers are not touched.
loadradar tra -l 100 -s 320 -a 1000 -f xxx2.tbin
Load programs from xxx2.tbin to location 1000, and load
1000 to start address register, and load the LC and SC.
loadradar tra -prog3 1345
Make "-prog3" an alias to "-a 1345" for use in a later
armradar tra
command. Nothing is loaded into the RC.
See also
armradar startradar stopradar printexperiment
radarloops getrepetitionperiod printradar
loadsetup --
Load an initial configuration to the analog receiver chain.
Synopsis
loadsetup
resetreceiver
Description
-> The command can be used to bring local oscillator
selection, etc, to default state (see selectlo).
-> This is done automatically by the runexperiment and
stopexperiment commands.
-> The default values are defined in a file
whos name can be found by the EROS
eGet rxifconfig
command.
logbook --
Write a message to the site's logbook.
Synopsis
logbook ?-force? <word> ?<word> ...?
Description
-> EROS automatically records certain key events of experiments to daily
"logbook" files. In addition, it is possible to write logbook entries
manually using the logbook command.
-> Normally the message, which is concatenation of the <word>s, is written
to the logbook only when the testexperiment mode is __not__ active,
that is, only during an experiment that has been started with
runexperiment, not with testexperiment, or when no experiment is
running. The flag -force can be used to force logbook entry
unconditionally, like when one wants to make an interactive entry when
a test is running. An empty message will never be written, not even
with -force. If the intended message contains the word "-force", use
the "-force" flag in front of the actual message <word>s.
-> The last few entries of the logbook can be inspected using
printlog. For more extensive inspection, the daily logbook files
currently are kept in site's server at locations like /kst/log/UHF/.
-> Note that EROS also keeps more detailed "technical" daily log files which
contain most of the messages shown in the EROS Messages window. These
files currently are in places like /kst/log/UHF/misc/, and can also
inspected using printlog.
ls --
List files as seen by the EROS Messages process.
Synopsis
ls ?OPTIONS? ?<pattern>?
Description
-> The command ls is EROS front-end to the standard Unix command
/bin/ls and accepts the same options. The essential difference is
that the Unix "ls" executes in the process where the command is
typed in, while the EROS "ls" lists the files as seen by the EROS
Messages process. This should be kept in mind, because the various
EROS processess may not even execute in the same computer and may
see a different set of files, and even the same computer, remotely
mounted files might have different names.
-> If you need to use the Unix "ls" directly, invoke the command as
"exec ls".
See also
pwd, cd
main --
Define an elan file "main program".
Synopsis
main <ArgumentList> <Body>
MAIN <ArgumentList> <Body>
Description
-> The command "main" or "MAIN" can be used to define an elan file BLOCK that
is automatically called by EROS when runexperiment command is given.
-> The elan file that contains a main or MAIN should not use an explicit
callblock or gotoblock to invoke the block.
-> The parameters of runexperiment are delivered to the MAIN as in the
example below.
Examples
The file myexp.elan could contain a MAIN defined as
MAIN { ScanName {User EI} {Height 270} } {
...
callblock $ScanName
}
and the experiment could then be started by
runexperiment myexp fm myscan1 fi 300
The optional parameters "myscan1", "fi", and "300" of the
runexperiment command are given to the MAIN.
There must not be any explicit invocation of the MAIN, like
??? callblock MAIN {*}[argv] ???
at the end of the myexp.elan file.
MAIN --
Define an elan file "main program".
See main
message --
Send a message to the EROS Messages window at a remote radar.
Synopsis
message <radar list> ?<word> <word>...?
Description
-> <radar list> can specify a single radar like U or K,
or can be a string like "KSV" specifying several radars.
-> The message is send when you push <cr> if the message is
a syntactically valid Tcl string at that point. It it is not a valid
string (say, a terminating quote is not yet there), the message is not
send, but instead a continuation line is offered (next bullet).
-> To send a multi-line message, the cleanest way is to
begin the message by a double quote and then
type each line separately, and finish with a double quote
as shown in the second example above. In the example, the
lone colon ":" is EROS secondary prompt, meaning that a
command is not yet complete, and so <cr> does not
execute the command. The final quote completes
the command, and the next <cr> sends the message.
-> The message is not echoed locally in the message
window, so if you want to track an exchange of messages,
you might to send the message to your own site also,
like in the second example below.
-> Experience has shown that in practice people seldom notice
that a message has arrived to the messages window :-(
You could try consolemessage instead.
Examples
K: message s This is a single-line message
K: message ks "This is three lines of input <cr>
: and will disply on <cr>
: three lines at the receiving site."<cr>
See also
consolemessage DISP
monitor --
Control EROS Monitor process.
Synopsis
monitor start|stop.
Description
-> The EROS Monitor process runs in a fairly tight (~200 ms) loop that
allows periodic checking and updating of various aspects of
the EROS system.
-> Normally, the loop must be kept active, but for debugging purposes,
looping might be terminated using monitor stop.
See also
ipcmonitor
powermonitor
mount --
Define data root directory, to take effect when the recorder is next time (re-)started.
Synopsis
mount ?<receiver>? ?<disk spec>?
Description
-> <disk spec> must be one of the predefined data paths like
"/data1". The paths are defined in the EROS configuration
file eros/boot/boot_config.tcl.(You may use the
command "eGet Disklist" to find the currently allowed
paths).
-> Alternatively, <disk spec> can be a symbolic name like "discN"
where discN refers to the N'th element in the
definition list (this option is not much used, and
may become obsolete in the future).
-> Use of the mount command in ELAN files should be avoided,
the command is meant for interactive use. Note also
that the command takes effect only after the recorder is
(re-)started. Use the command restartdata to achieve this.
Examples
mount /data2
mount pla /data1
mount ion disc2
See also
printdataaccess recorder restartdata startdata
moveazimuth --
Change antenna azimuth direction, keep elevation intact.
Synopsis
moveazimuth ?OPTIONS? <angle>
Description
-> Antenna azimuth is increased or decreased by a given angle (degr),
from the current position. Elevation is kept on the
current value.
-> <angle> can be a numeric expression like 630-145, and can also
contain the keywords min|azmin, max|azmax and now|aznow.
-> The command is a wrapper around getdirection and
pointdirection, and therefore the final azimuth angle,
aznow+Angle, must at least fit in the interval ]-360,720[, else
an error is raised. With -nooptimization, there are further
restrictions.
OPTIONS
-acu: Both the current direction and the azimuth Angle change are
interpreted as ACU values. Without -acu, the values refer to true
beam direction values.
-nooptimization: Without -acu, the implied final azimuth angle aznow+Angle
must be in the interval [90 630] in KST and in [-270 270] at ESR, else an
error is raised; with -acu, the implied final azim angle must be
in the site-dependent maximal azimuth interval, see pointdirection.
The antenna will be pointed to that azimuth.
Without -nooptimization, azimuth slew is optimized so that
the antenna is pointed to the angle aznow+Angle, but only modulo
360 degr, and in such a way that the required azimuth motion from
the current position is as small as possible.
An implication is that with -nooptimization, if the antenna
already is at AZMAX, then the command
moveazimuth -noopt +1
will cause an error, and the command
moveazimuth +1
will cause an azimuth movement by -359 degrees.
-test: The azimuth and elevation that would result from the command
are returned, but no actual pointing is done.
Examples
moveazimuth -10
==> decrease beam azimuth by 10 degrees, beam elevation is not changed.
[moveazimuth -acu 10
==> increase ACU azimuth by 10 degrees, ACU elevation is not changed.
moveazimuth 0
==> if antenna is moving, stop the motion, else do nothing.
moveazimuth -noopt +360
==> increase azimuth by 360 if possible, else give an error.
Note that without -noopt, the command never does anything.
moveazimuth -noopt min-now
==> move azimuth to the AZMIN direction (90 at KST, -270 at ESR).
See also
getdirection moveelevation pointdirection printantenna
moveelevation --
Change antenna elevation angle.
Synopsis
moveelevation ?-acu? ?-test? <angle>
Description
-> Antenna elevation is increased or decreased by the given Angle (degr),
from the current position. Azimuth is kept at the current value.
-> The change <angle> can be a numeric expression like 90-15, and
can also contain the keywords elmin elmax now|elnow.
-> The implied final elevation angle elnow+Angle must be in the
site's legal elevation interval, else an error is raised.
-> The command is a wrapper around getdirection and pointdirection.
OPTIONS
-acu: Both the current direction and the elevation change Angle are
interpreted as ACU values. Without -acu, the values refer to true
beam direction values.
-test: Return the would-be final direction angles azimuth and elevation,
but do not actually point the antenna.
Examples
moveelevation -10
==> lowers elevation by 10 degrees.
[movelevation] 90-now
==> moves elevation to zenith.
[movelevation] -acu elmin-now
==> moves elevation to the lowest allowed value.
See also
getdirection moveazimuth pointdirection
msdiff --
Difference between two {sec usec} times in milliseconds.
Synopsis
msdiff sec2 usec2 sec1 usec1
nedit --
Edit files in the "nedit" editor.
Synopsis
nedit <pattern>
nedit +<linenumber> <filename>
Description
The implied files are opened in the nedit editor,
in a single window (multiple tabs).
The command is allowed only on the local EROS console.
noiseinjection --
Enable/disable noise injection if in computer mode.
Synopsis
noiseinjection Polarization OnOff (KIR and SOD)
noiseinjection OnOff (UHF and VHF)
Description
OnOff is either "on" or "off".
Polarization is "both" or "hor" or "ver".
The command is ignored at ESR.
Examples
noiseinjection on
noiseinjection both off
noiseinjection ver off
noiseinjection hor on
nop --
No operation
Synopsis
nop ?arg...?
Description
This function does nothing, but can be useful to suppress
unwanted printout in interactive commands. For instance, if a
command, such printexperiment, returns a long string which we only
want to assign to a variable but not print out, we can use
set x [printexperiment];nop
parkantenna --
Point antenna to a site-dependent parking direction.
Synopsis
parkantenna
Description
-> Site staff might want the antenna to be pointed to some
specific direction when antenna is not used for extented
periods. You might consider giving this command even to
the remote sites when you are done with your experiment.
-> The command is ignored at ESR and VHF. In the current
implementation, the direction is hardcoded into the
routine parkantenna() in the file eros_commands.tcl.
patch --
Modify a running EROS.
Synopsis
patch File Process ?Process ...?
Description
-> The file File is sourced in the indicated EROS process(es).
-> The patch command can be given interactively, or
from an ELAN file. The patch can be used as a remote
command, too.
-> The Process can be either a window name like
"messages" or "console", or the a wish application
name like "exprun" or "compro". If Process=="all", the
patch is applied to all standard EROS processes.
-> In this implementation, only the five standard processes
are available for patching, so that at ESR, the
txvme and plasmavme cannot be patched with this command.
Example
patch /kst/eros5/eros/lib/eros_commands.tcl all
See also
loadfile [make]
peekvme --
Read value(s) from a receiver crate computer's VME address space.
Synopsis
peekvme ?<Receiver>? ?-chd? <Address> ?<Length>?
Description
-> <Address> must be specified as
<Space>.<Addr>
where
<Space> = s|d|e|t|S|T|D|E|none. The space s ("short") makes A16D16
accesses, the space d ("standard") makes A24D32 accesses, the space
e ("extented") makes A32D32 accesses, the space t makes A24D16
accesses. If none is given, e is assumed. <Addr> specifies the VME
start address of the block to be read. The address is always assumed
to be in hex, and can be typed in with or without the standard
c-language hexa prefic (0x).
-> <Length> specifies the number of items to read. For "real" data (option
-r, the default), peekv reads exactly LENGTH items having bit length
implied by the VMEspace, for "complex" data (option -c), peekv reads
2*LENGTH items, assuming that complex data is packed as
[Re Im Re Im ...].
Examples
peekvme ion s.3100 0x10
peekvme -cd C0000000 16
See also
pokevme
planetinfo --
Return Az, El, RA and DE of some solar system bodies.
Synopsis
planetinfo <Name> ?<TimeSpec>?
Description
-> If <TimeSpec> is not given, "now" is assumed.
-> The return value is a 4-element list, containg
Azim(degr) Elev(degr) RA(hours) and Decl(degr).
-> RA and Decl refer to the given time.
Examples
planetinfo moon
planetinfo jup* 21:12:34
planetinfo mars "Aug 20 21:12:34 2006"
See also
celdirection
pointcelestial
Point to a specified celestial position.
Synopsis
pointcelestial <name> ?<time spec>?
pointcelestial <RA> <declination> <time spec>
Description
-> The pointing is done immediately, to the az,el of the given
celestial position at the given time.
-> If <time spec> is not given, "now" is used, but then note that for
any sizeable antenna move, the source will not any more be in that
position when the movement completes.
Examples
pointcelestial cas-a
pointcelestial moon 10:30
pointcelestial {11 12 13} {-1 30 00} 10:30
See also
celdirection celsource trackcelestial trackgalactic
pointdirection --
Point antenna to given azimuth and elevation.
Synopsis
pointdirection ?<OPTIONS>? <Azimuth> <Elevation>
Description
-> <Azimuth> (degr) and <Elevation> (degr) are the required local azimuth
and elevation. Azimuth 0 is to the North, 90 to the East.
-> Without options, the <Azimuth> and <Elevation> refer
to the desired "beam direction". Moreover, the default
behaviour (at UHF only) is to minimize the amount of azimuth
slewing resulting from the pointing command.
-> <Azimuth> and <Elevation> can be numeric expressions like
180+10, and can include at least the following keywords:
AZ keywords: azmin|min azmax|max now
EL keywords: elmin|min elmax|max zenith up down now
The keyword "now" means current position.
-> Without the -acu option, the input <Elevation> must be such
that the offset-corrected elevation EL_acu,
EL_acu = Elevation+EOFF,
respects the HW limits.
-> Without the -acu option, the input <Azimuth> can be any value
between -360 degr and +720 degr, end points excluded, and Eros
maps the input to the valid azimuth interval by adding or
subtracting a multiples of 360 degr, depending also on the state
of the optimization-control flags (-cw|-ccw|-noopt), and, at ESR,
also about the -inv flag.
Without the -acu option, the valid <Azimuth> interval at all
sites is precisely 1.5*360 degr (which is somewhat less than the
actual HW limits available when using -acu). How this one-and-a-half
times the full circle is represented internally is site dependent,
and at ESR, also depends on the flag -inv.
* At UHF, the azimuth interval is [90,630], end-points included.
* At ESR, normal mode, the azimuth interval is [-270,+270].
* AT ESR, invert mode, the azimuth interval is [-90,+450].
The 540 degrees total azimuth interval is divided into two 270 sectors,
or "wraps", called the CW sector and the CCW sectors.
The sector limits are the following:
* UHF, CCW is 90 <= AZ <= 360; CW is 360 < AZ <= 630.
* ESR, normal mode, CCW is -270 <= AZ <= 0; CW is 0 < AZ <= 270.
* ESR, invert mode, CCW is -90 <= AZ <= 180; CW is 180 < AZ <= 450.
OPTIONS
-acu (or -unc) : Do not apply any pointing offsets to the input
Azimuth and Elevation values. By default, the offsets are applied.
With this option, the Azimuth and Elevation must respect the
site-dependent azimuth and elevation HW limits, else in input error
is raised. The HW limits are defined in the file
site_definitions.tcl in the EROS source distribution.
As of July-2010, the Prelimit limits used in Eros are
- - - - - - - - - - - - - - - - - - - - - - - - -
TRO: 86.20 <= AZ <= 630.54; 1.44 <= EL <= 96.13,
SOD: 82.4 <= AZ <= 632.27; 2.33 <= EL <= 100.75,
KIR: 90.0 <= AZ <= 630.00; 1.80 <= EL <= 95.3.
ESR -270 <= AZ <= 270 ; 0 <= EL <= 180
These are the Prelimits, EROS provides a small extra safety margin.
The actual values that Eros uses can be queried at runtime as e.g
Query AZMAX(T), or Query ELMIN(K).
-inverted : The ESR antenna can be moved 180 degrees in the vertical
plain, that is, the HW "elevation parameter" EL_acu can have values
from 0 to 180 degr. We call the situation when EL_acu > 90 degr an
"inverted" pointing, and this EL_acu can be directly controlled
within its full range by using the -acu options. The purpose of the
-inv flag is to make it possible to always use a physical Elevation
parameter between 0 and 90 degr in the command, so that the Azimuth
parameter can then be interpreted as a physical azimuth (mod 360).
With the -inv flag, the the input Azimuth and Elevation are
mapped by Eros to values
* El_inverted = 180 - Elevation
* Az_inverted = Azimuth + 180.
The Az_inverted may then be further mapped by a multiple of 360 degr,
depending on wrap-control options.
-cw|-ccw|-noopt : Turn off automatic azimuth-slew minimization, so that
the user has an explicit control onto which part of the
540 degr azimuth interval the antenna moves as a result of a
pointing command. The -noopt flag ("no optimization") causes the
input Azimuth mapped to the 540 range, and that value to be given
in the pointing HW. For example, at KST, with -noopt, the Azimuth
value 30 would be mapped to the nearest value mod 360 in the [90,630]
interval, which is 390. Thus, the pointing would go the the CW wrap.
With the -cw and -ccw options, the input Azimuth is mapped to the
nearest value mod 360 to the corresponding wrap, if possible. If
the input Azimuth can't be mapped to the requested wrap, then the
other wrap is used, so that the command always succeeds. Thus, the
options -cw and -ccw must be viewed as "hints" rather than
absolute requests. (This hint-only feature make it possible to
use -cw and -ccw also in the tristatic pointing commands like
pointgeographic, where it may not be immediately obvious to which
wrap the local pointing could actually fit.)
At KST, slew-minimization is done by default, based on the
current azimuth, and the desired Azimuth mod 360. At ESR, -noopt is
for historical reasons the default. To use optimization at ESR, the
option -opt is required explicitly.
-opt : Turn on automatic azimuth-slew minimization. This is needed only
at ESR, where azimuth slew optimization is for "historical reasons"
turned off by default for the pointdirection command.
-test : Do not perform the actual pointing, but only return the
end result of the azimuth and elevation mappings.
Examples
-> To point antenna beam to north-west at 30 elevation, use
pointdirection 315 30
or
pointdirection -45 30
At KST, both of these give ACU azimuth near 315, at ESR,
both give ACU azimuth -45. Note that this position gives no
possibilities to optimization because the wrap is uniquely fixed.
At ESR, with inverted pointing, one could use also any of
pointdirection -inv 315 30 (goes to icw wrap)
pointdirection -inv -45 30 (goes to iccw wrap)
pointdirection -inv -opt 315 30 (goes either to icw or iccw).
-> To point antenna beam to south-east at elevation 5 degr and also
ensure that antenna goes to the first wrap so that the antenna
can move continously clockwise as long as possible, use
pointdirection -ccw 135 5
-> To force antenna ACU to azimuth 180, elevation 30, use
pointdirection -acu 180 30.
-> At ESR, with -acu, it is necessary to use elevations
greater than 90 to get inverted pointing, for example, the command
pointdirection -acu 180 150
directs the antenna to 30 elevation towards north. It is
possible to use elevation > 90 also without -acu, but this
can become confusing, and one should use -inv and elevations
less than 90 to achieve inverted pointing.
Note
For diagrams of the azimuth mapping, and for more examples, see links
on the main page of EROS online documentation.
See also
moveazimuth moveelevation pointgeographic pointrrange
printantenna
pointgeographic--
Point antenna using geographic coordinates of the common volume.
Synopsis
pointgeographic ?OPTIONS? <latitude> <longitude> <altitude>
Description
-> Latitude and Longitude are in decimal degrees, Altitude is in km.
-> Latitude, Longitude and Altitude can be numeric expressions like
69.0+1.0, and can also contain as keywords EISCAT site coordinates
e.g. lat(e)+1, lon(t) and alt(k)+300.
-> Unless -nochangedelay is used, the clock delay is set automatically
in Kiruna and Sodankyla. The delay is also computed in Tromso,
but has no effect there.
OPTIONS
-setpol: If this option is used, in Kir and Sod the polariser is
automatically set, at other sites the parameter is ignored. However,
after the "VHF conversion", the polarizer HW is disconnected, so this
command has no effect even in KIR and SOD (apart from still showing
the would-be polarizer settings in printantenna). (clockwise) and
-cw:
-ccw: (counter-clockwise) can be used to force pointing to the specified
azimuth wrap when possible. See pointdirection.
-inv: (only at ESR) causes "inverted" pointing, that is, elevation
larger than 90 degr. The flag is ignored at the other sites.
-test: Results in no actual pointing, instead, a prediction of the azimuth
and elevation that would be given to the pointing system is returned.
-nochangedelay: Inhibits any touching of the clock delay by this command.
Note that this does not imply that the clock delay would be zero
afterwards, it just implies that the current delay is not changed.
The delay is initially zero, when the radar controller is first
started at the start of an experiment, but by default each tristatic
pointing command in KIR and SOD changes the delay to PPD+PPD_OFFSET.
(The change takes effect at the start of next integration period, or
the next-but-one integration period, depending whether the delay is
being increased or decreased.)
Examples
pointgeographic 69.0 19.1 300
pointgeographic -inv -ccw lat(e)+1 lon(e)+2 300
pointgeographic -nochangedelay 69.0 19.1 300 ==> even in KIR|SOD, do not change clock delay
rem k pointgeographic 69.0 19.1 300 -test ==> return would-be KIR azim and elevation
See also
pointdirection pointrheight pointrrange printantenna
setclockdelay setppdoffset
setpolariser
pointpole --
Point antenna towards celestial north pole.
Synopsis
pointpole
Description
The command is shorthand for pointdirection 360 Elev
where Elev is equal to the site's geographic latitude.
pointrheight --
Point antenna using the bi-static reference height mode.
Synopsis
pointrheight ?<OPTIONS>? <ref azim> <ref elev> <height>
Description
-> The pointing parameters <ref azim> (degr), <ref elev> (degr) are
direction angles from the current reference site to the common
volume, and <height> (km) is the altitude of the common volume above
the spheroid.
At EROS boot-up, the reference site is initialized to
Tromso at the UHF sites, and to ESR at ESR. The reference site
can be changed by the command changersite.
AzRef, ElRef and Height can also be simple numeric expressions,
and Height can involve an EISCAT site altitude as e.g. alt(T)+300.
-> The input parameters must be such that a valid AZ, EL pointing
can be generated both at the reference site and at the local site,
even though the pointing is of course only done at the local site.
See pointdirection for the parameter limits.
-> If the -nochangedelay option (see below) is not used, the clock delay is
set in Kiruna and Sodankyla to PPD+PPD_OFFSET. The delay is also computed
and displayed in Tromso, but has no effect there.
Note that the delay is implemented by delaying the receiver radar
controller (re-)starts, and takes effect at next integration period
boundary or at the next-but-one integration period boundary.
This requires that knowledge of the integration period and
radar controller start time are available. Therefore the clock
delay will NOT be set in the HW if the radar controller is not running,
even though the printantenna command shows the delay's value.
-> The command terminates an ongoing trackcelestial (except with -test).
OPTIONS
-setpol: If this flag is used, also the polariser (in Kiruna and Sodankyla)
is set to correspond to the pointing, using setpolariser.
Default is not to give an automatic polarizer command.
The flag has no effect if not in Kir or Sod.
-inv: At ESR, the flag -inv causes inverted local pointing, that is, elevation
greater than 90 degr. The flag has no effect at the other sites.
See pointdirection for description of the inverted mode.
-cw|-ccw: These flags disable the automatic azimuth slew size optimization,
allowing the user explicitly direct the local pointing to the
specified azimuth wrap, either the clockwise or the counter-clockwise wrap,
see pointdirection.
Default at UHF is to use optimization, that is, Eros selects the
wrap which results in the shortest azimuth slew from the current position.
At ESR {-?-documentation needed-?-}.
-test: If this flag is used, no actual pointing is done, but instead
the local azimuth and elevation are returned in the form they would
be given to the AZ/EL-pointing system.
-nochangedelay: Inhibits any touching of the clock delay by this command. Note that
this does not imply that the clock delay would be zero afterwards, it just implies
that the current delay is not changed. The delay is initially zero, when the radar
controller is first started at the start of an experiment, but by default each
tristatic pointing command in KIR and SOD changes the delay to PPD+PPD_OFFSET.
(The change takes effect at the start of next integration period, or the next-but-one
integration period, depending whether the delay is being increased or decreased.)
Examples
pointrheight -ccw 180.6 78.3 300
pointrheight -setpol 180.6 78.3 300
pointrheight -nochangedelay 90 78 850
pointrheight -inv 181 81.6 300+10
k pointrh -ccw 180.6 78.3 300 -test
==> return KIR local Azim and Elev that would result from the command
See also
changersite
pointdirection pointgeographic pointrrange printantenna
setclockdelay setppdoffset
setpolariser
pointrrange --
Point antenna using the "reference range" mode.
Synopsis
pointrrange ?<OPTIONS>? <ref azim> <ref elev> <ref range>
Description
-> The parameters <ref azim> (degr), <ref elev> (degr) and <ref range>
(km) refer to the current "reference site". At EROS boot-up, the
reference site is initialized to Tromso at the KST sites, and to ESR
at ESR. The reference site can be changed by the command
changersite. <ref azim>, <ref elev> and <ref range> can also be
simple numeric expressions.
-> The input parameters must be such that a valid AZ, EL pointing
can be generated both at the reference site and at the local site,
even though the pointing is of course only done at the local site.
See pointdirection for the parameter limits.
-> If the -nochangedelay option (see below) is not used, the clock
delay is set in Kiruna and Sodankyla to PPD+PPD_OFFSET. The delay is
also computed and displayed in Tromso, but has no effect there.
-> Note that the delay is implemented by delaying the receiver radar
controller (re-)starts, and takes effect at next integration period
boundary or at the next-but-one integration period boundary. This
requires that knowledge of the integration period and radar
controller start time is available. Therefore the clock delay will
NOT be set in the HW if the radar controller is not running, even
though the printantenna command shows the delay's value.
-> The command terminates an ongoing trackcelestial (except with
-test).
OPTIONS
-setpol: If this flag is used, also the polariser (in Kiruna and Sodankyla)
is set to correspond to the pointing, using setpolariser. Default
is not to give an automatic polarizer command. The flag has no effect
if not in Kir or Sod. Presently, the flag has no effect even in Kir
and Sod either, as the polarizer hardware was bypassed in connection
of the "VHF conversion".
-inv: At ESR, the flag -inv causes inverted local pointing, that is, elevation
greater than 90 degr. The flag has no effect at the other sites. See
pointdirection for description of the inverted mode.
-cw|-ccw: These flags disable the automatic azimuth slew size optimization,
allowing the user explicitly direct the local pointing to the
specified azimuth wrap, either the clockwise or the counter-clockwise wrap,
see pointdirection.
Default at UHF is to use optimization, that is, EROS selects the
wrap which results in the shortest azimuth slew from the current position.
-test: If this flag is used, no actual pointing is done, but instead
the local azimuth and elevation are returned in the form they would
be given to the AZ/EL-pointing system.
-nochangedelay: Inhibits any touching of the clock delay by this command. Note that
this does not imply that the clock delay would be zero afterwards, it
just implies that the current delay is not changed. The delay is
initially zero, when the radar controller is first started at the
start of an experiment, but by default each tristatic pointing
command in KIR and SOD changes the delay to PPD+PPD_OFFSET. (The
change takes effect at the start of next integration period, or the
next-but-one integration period, depending whether the delay is being
increased or decreased.)
Examples
pointrrange 180.6 78.3 293.5
pointrrange -setpol 180 73.8 300
pointrrange -inv 181 81.6 300+10
pointrrange -nochangeclockdelay 90 73.8 900
See also
pointrheight [pointgeograhic] pointdirection changersite
setpolariser
inhibitantenna allowantenna
setclockdelay setppdoffset
pokevme --
Write a value to receiver crate computer's VME address space.
Synopsis
pokevme ?Receiver? Addr Data ?Ncopies?
Examples
pokevme ion s.3008 0x2f
pokevme C000_0000 1,0 0x10
See also
peekvme
powermonitor --
Turn on|off transmitter power updating.
Synopsis
powermonitor ?on|off?
Description
-> EROS Monitor process periodically tries to update the transmission
power value in the local EROS shared memory so that the value can
then be included in the data dumps.
-> In KIR and SOD, the power monitor fetches power data from the
VHF EROS shared memory, by remotely executing rtpeek in the VHF system.
If the VHF EROS goes down, an error message is shown once in the
KIR and SOD EROS Messages window, and then again once when the VHF EROS
is up again.
-> In UHF and VHF systems power monitor reads power data from a file
(such as /kst/transpar/vhf.txt). Reading and/or decoding that data does
not always succeed, and in the EROS log files, there are relatively
frequent error messages to that end. The TX data files are updated by
a program running outside the EROS system.
-> In the ESR system, power monitor takes some power from a file and some
power data directly from special power meters (by executing a shell
script get_pow.sh which contacts the ESR "power" computer by ssh to get
the power data via the so called "gadgetbox" software).
poweroff --
Bring antenna off-line.
Synopsis
poweroff
Description
Power OFF the esr antenna, set ACU to standby at the other sites.
See also
poweron setacu
poweron --
Bring antenna on-line, ready for pointing commands.
Synopsis
poweron
Description
Power ON the esr antenna, or set ACU to computer mode at other sites.
See also
poweroff setacu
printantenna --
Return a string of various antenna pointing related info.
Synopsis
printantenna ?-eros3?
Description
The returned info depends on the previous pointing command and
on the site. If the previous command has been such that the
common volume is known, the common volume is specified in
various ways. If the common value is not known, only azimuth
and elevation are shown. In addition to the pointing direction,
information of the antenna slew state is given.
During celestial tracking, use the command printcelestial.
The flag "-eros3" changes the displayd info to correspond to
that used in older versions of EROS.
Example
Soon after giving the command pointrrange 181 77.3 300 -setpol
in Sodankyla, printantenna resulted in the following:
----------------------------------------
online A moving E ready Refsite T (1)
setpol 255 -18 unc 272 -18 ready (2)
A/E 288.67 36.97 => 304.39 36.96 (3)
Acu 288.59 38.22 => 304.35 38.22 (4)
Range 469.54 Delay 2567+0 (5)
pointrrange 181.00 77.30 300.00 (6)
pointgeogr 69.021 19.200 293.07 (7)
----------------------------------------
(1) Antenna status: online|offline (offline = "standby")
Azimuth still moving, Elevation already ready.
Current refence site is Tromso (use changersite to change it).
(2) Polarizer phase=255, amplitude -18, including offsets, so this is
the actual porariser setting (if offset model is correct).
Then the "uncorrected" polariser values, which should correspond
to the value readaable in the antenna control unit.
The polariser ready flag.
(3) Current true pointing direction (azimuth and elevatio) and
the commanded azimuth and elevation. The "=>" arrow tells
that antenna is still slewing.
The true direction is found by reading the raw values from
the antenna hardware (see (4)), and making offset correction.
(4) The current azimuth and elevation as read from hardware, and
the commanded values (see readantenna.
(5) Commanded range of the common volume from the local site (km).
Commanded clock delay (done automatically and unconditionally
by the pointing command). The clock delay is the sum of
the pulse propagation delay (PPD, now 2567 us) and the PPD offset
(now 0 us). The PPD can be changed by setppdoffset, followed
by setclockdelay .
(6) The commanded direction of the common volume, as would be specified
in a pointrrange command.
(7) The commanded direction of the common volume, as would be specified
in a pointgeographic command.
printcelestial --
Return a ready-to-print string of tracking info
Synopsis
printcelestial
Description
Print information about the ongoing or scheduled celestial
source tracking (see trackcelestial).
printcomm --
Return info about the state of EROS interprocess communications.
Synopsis
printcomm ?<process>...? ?-p <pattern>? ?-p <pattern> ...?
Description
-> EROS interprocess communication (IPC) is implemented using a slightly
modified version of the standard Tcl "comm" package found in tcllib.
Most of the state info of the comm package is kept in a global array
called ::comm::comm. Each EROS process has its own version of that array,
and the printcomm command prints out selected part of the array, with
some formatting.
-> <process> is name of the EROS process, as shown in the title line of the
EROS window (character case is ignored, and the name can be abbreviated
from the end). <process> can also be "all". The available names can be
found using
eros names.
-> <pattern> is used to match element names in the comm:comm array. Some
possibilities are shown below, for more, refer to comm package documentation,
or use the Tcl command "array names ::comm::comm" to show all available names.
Examples
printcomm
printcomm ioncorr
printcomm mes elan mon -p peak
printcomm mon -p pending
printcomm all -p port
printdataaccess --
Return a ready-to-print string of data access info.
Synopsis
printdataaccess
printexperiment --
Return a ready-to-print string of experiment info.
Synopsis
printexperiment
Description
Soon after giving the command "[runexperiment] tau2pl fm"
the printexperiment command displayed the following:
EXPERIMENT (SOD) 23-Feb-2007 23:36:21.9 (0)
---------------------------------------
Exp file : tau2pl.elan (1)
dir : /kst/exp/tau2pl (2)
state : RUNNING since 23-Feb 23:35:39.3 (3)
E-time : 23-Feb 23:36:00.0 (4)
Block : cp1 tau2pl 292.9 (5)
launch: 23-Feb 23:36:00.1 (6)
B-time: 23-Feb 23:36:00.0 (7)
Cont.at : 23-Feb 23:37:00.0 (8)
Rad contr : started 23-Feb 23:36:00.0 (9)
Latest : /data/RT2@sod.mat (10)
: 23-Feb 23:36:16 (6 sec ago) (11)
- - - - - - - - - - - - - - - - - - -- - - - - - - -
(1) The ELAN file name.
(2) The directory part of the pathname of the ELAN file.
(3) State either "running" or "stopped".
(4) Experiment commanded start time as specified or implied by
the runexperiment command, see also the description
of the startradar command.
(4.5) If there is a scheduled stop (see stopexperiment),
the stop time is shown after E-time.
(5) Name and call parameters of the currently executig BLOCK.
(6) Time when the currenly executing BLOCK was entered,
see gotoblock, callblock.
(7) The specified or implied start time of the currently
executing block, see gotoblock, callblock.
(8) The "continue-at" time, which is the time when
the currently executing "sleep" command (SYNC or AT)
expires, and the ELAN program flow moves on.
(9) Radar controller start time.
(10-11) Latest data dump's file name and dump time.
printlog --
Show last few messages from a site's EROS log file.
Synopsis
printlog ?-logbook|-testlog|-eroslog|-errorlog? ?N?
Description
Show N lines from the indicated log file.
-eros ==> from the end of the eros log file
-test ==> from the end of the eros test log file
-err ==> from the beginning of the eros error log file
Default is to show 10 lines from the last active of the
eroslog or erostestlog.
Examples
printlog
printlog 10
printlog -err 20
See also
lasterror
eros lasterror
printradar --
Synopsis
printradar ?RAD?
Description
-> RAD = ion|pla|rec|trans
-> In this first version, we only show the RC register set,
xx00 RC start address, LSB
xx02 RC start address, MSB
xx04 RC loop counter
xx06 RC sync counter
xx08 RC command word
xx0A RC status word
printreceiver --
Show information about the state of the analog receiver.
Synopsis
printreceiver ? -raw ?
Description
Print receiver LO1, LO2 and attenuator settings (and pointing).
Currently, the command is only available at UHF and VHF.
Examples
RECEIVER (UHF) 13-Feb-2014 12:48:53
-----------------------------------
ION PLA
Azimuth : 180.88
Elevation : 22.27
Local osc 1 : 812*
Attenuator : 5 8
Local osc 2 : 128 122
lock : ok ok
-
RECEIVER (VHF) 13-Feb-2014 13:07:15
-----------------------------------
A B
Elevation : 90.0 92.0
: 91.0 93.0
Panel path : split*
LO control : rec
Local osc 1 : 298 298
Attenuator : 7 5
Local osc 2 : 84 84
lock : ok ok
See also
transferlo selectlo setattenuator
printtransmitter --
Show information about the (UHF|VHF) transmitter.
Synopsis
printtransmitter
Description
Print transmitter info.
pwd --
Print working directory of EROS Messages process.
Synopsis
pwd
Description
The EROS command pwd goes to the EROS Messages process, and
performs the standart Tcl pwd command there, and returnes the
value. This value is not necessarely the actual working directory
of the process where the pwd command was typed-in. If you want
to check what is the actual working directory, use the standard
Tcl pwd command which in EROS is renamed to "Tcl_pwd", in the
appropriate EROS window, or use the standard Unix pwd as "exec pwd".
See also
ls cd
Query
Return value of any EROS global variable maintained by the Messages process.
Synopsis
Query <variable name>
Description
Use the internal IPC command "Send" to return the value of any global variable
maintained by the EROS Messages process.
Examples
Query ELMIN(T)
Query LAT(S)
Query mpv(continue_at)
radarinfo --
Manage radarinfo database.
Synopsis
ri SUBCOMMAND RCNAME prog?_?NAME ARG ?ARG ...?
ri SUBCOMMAND RCNAME.NAME ARG ?ARG ...?
ri @VARNAME args
ri SUBCOMMAND @VARNAME ?VALUE?
Description
The purpose of the radarinfo is to introduce EROS-wide, experiment-
related, variables which can be accessed both from the ELAN file and
from the command line. This is somewhat in the same spirit as with the
EROS upar parameters, but with more flexibility both in notation and
in usage. An important difference to the upar parameters is that EROS
itself can, and will, implicitly set, modify, and make use of many of
the parameters. For example, the loadradar command reads information
from the header of the RC program file and saves the rep period and the
duty cycle to the database. This in turn makes it possible for the
armradar command to compute the proper loop counter and sync counter
values based only on a given integration period (which itself can also
be in the radarinfo, but must be put in there explicitly).
At present, radarinfo contains mostly RC program related parameters,
like program start address, file name, loop counter value, rep-period,
and the like. These parameters are conceptually grouped to records which
are tagged by the RC name and the RC program name, like "ion.myprog".
Equivalently, one can use the keyword "prog" and a syntax like "ion
prog_myprog". (The underscore is dropped if myprog is only a single
decimal digit 1-9.) To access an individual record member PAR, one uses
the syntax -PAR. For example, the repetition period of the tx program
"myprog" can be referred to either by "tx.myprog -rep" or "tx
prog_myprog -rep". EROS allows more descriptive program names than just
progN, but nevertheless, we call the RC program ralated radarinfo items
progN-items. Later other kind of items like receiver channel related
items may be added.
Besides the progN parameters, radarinfo also keeps general-purpose
EROS-wide variables, which we call here the @-variables (because their
names must start with an "@"). These parameters must be explicitly
managed by the user, EROS does not set or modify them during a running
experiment (but see paragraph D, below).
A. The subcommands related to progN parameters are the following.
set Set one or more parameters for given RC programs progN. If
the progN does not yet have an entry in the database, a new entry
is created. Note that loadradar typically defines a progN for a
program and at the same time, sets the start address in radarinfo.
get Make inquieries on the parameters of one or more progN. The output
is a list if Items, one Item for each progN. Such an Item itself is
a list of parameter values, one element for each PAR specified in
the command. If a VAL for a PAR does not exist in the database, -1
is returned. (If a requested progN does not exist in the database
at all, an empty Item {} is returned for it.).
lget ("long get") Make inquiries on the database, allowing glob
pattern to be used (see progPAT below). The return list contains,
in addition of the requested parameter values, also parameter
names and the progN names. The command is mainly intented for
internal EROS use.
delete|rm Remove (permanently) items from the database. The command
is automatically issued by EROS at the end of an experiment to
clear the whole radarinfo database.
print Print items to screen, one progN's items per line. Print is the
default subcommand, so that "radarinfo RCNAME" displays the whole
database for RCNAME.
RCNAME = rx|rec|tx|tra|ion|pla
progN The "N" here can be any sequences of chars, numbers and
underscores.
For longer program names of type prog_XXX, instead of the syntax
"RCNAME prog_XXX", one can also use the syntax "RCNAME.XXX" .
progPAT Some of the subcommands accept a glob pattern PAT as part of the
prog name specification. In current version, only the wildcard
"*" is accepted.
The accepted parameter selectors -PAR are listed below ("*" means any
sequence of chars). The representation in brackets gives the name of the
PAR as displayed by the ri print command.
-a|-sa [sa] Program start address in RC memory (in terms of R/C words).
-A|-la [la] Program file's load address in RC memory (in terms of R/C words).
-l|-lc|-loop* [lc] Loop counter (minimum VAL is 1)
-s|-sc|-sync* [sc] Sync counter (minimum VAL is 0)
-r|-rep* [rep] Repetition period, VAL in fractional microseconds
-f|-fil* [fil] RC program binary file name
-d|-dc|-rfd* [rfd] RF duty cycle, VAL in percentage.
-n|-len* [len] RC program length in terms of RC words.
-all All currently defined parameters (not allowed with
get and set).
B. The subcommands related to @-variables are the following.
@NAME This returns the current value of the variable NAME.
@NAME VAL This sets VAL as the value of the variable NAME. The
value can be any valid tcl variable value.
unset @PATTERN This removes all matching variables from rdarinfo.
names @PATTERN This return names of the matching @-variables
C. The commands loadradar, armradar and startradar recognize
the lone @-symbol and a @-variable in a place where a parameter value is
expected and fetch the appropriate value from the radarinfo, without the
need of an explicitly call to radarinfo. For example, if the
progN-parameters loop counter (lc) and sync counter (sc) have been defined
for tx.myprog, then one can say
armradar tx.myprog -lc @ -sc @
instead of the tedious
armradar tx.myprog -lc [ri get tx.myprog -lc] -sc [ri get tx.myprog -sc]
And if the @-variable @my_tbin has been set in radarinfo, one can say
loadradar tx -f @my_tbin -A 0
instead of
loadradar tx -f [ri @my_tbin]
D. The whole radarinfo database is implicitly cleared at experiment start,
before invoking the ELAN file. (((We need the possibility to save|recall
the database to|from a file to get persistence over experiment
boundaries when required, but this feature is not yet implemented.)))
Examples
ri rx delete -all
ri set ion.myprog -sa 0 -lc 7 -sc 3200 -rep 714240
ri set tx.myprog -sa 1000 -lc 7 -sc 3200 -rep 714240 -rfd 11.8
ri get tra prog1 prog2 -a
==> 0 1000
ri get tra prog1 -sa -loopc
==> {0 7}
ri get tx prog1 prog2 -sa -lc
==> {0 7} {1000 7}
ri lget tra prog1 prog2 -sa -lc
==> {prog1 {sa 0 lc 7}} {prog2 {sa 1000 lc 7}}
ri @my_tbin /kst/exp/something/my_progs.tbin
==> /kst/exp/something/my_progs.tbin
ri @my_tbin
==> /kst/exp/something/my_progs.tbin
radarloops --
Find radar controller loopcounter and synccounter values.
Synopsis
radarloops Iper Rep
Description
Given integration period and radar controller loop time,
the "REP" time, compute radar controller loop counter
value and sync_error counter value to be used in the
loadradar command.
-> Iper is the integration period. Default unit is seconds,
but an embedded unit can be used, and then Iper can also
be in microseconds, so that "6.4", "6.4s" and "6400000us"
are all accepted to mean 6.4 seconds.
-> Rep is the radar controller loop time, the "REP". It also
can be seconds or in microseconds, default is microsecs.
-> Return value is a two element list {LoopC SyncC}. These
are the values that should be used in the loadradar
command. (The actual values loaded to RC registers are
one less than these.)
-> A warning is issued if the implied SyncC time would be
longer than the sync time tick interval, 10ms.
Examples
radarloops 5.0s 714240
==> 7 3200
See also
loadradar
rcversion --
Return info about radar controller firmware version.
Synopsis
rcversion tra|rec|ion|pla
Description
Read the first 100 16-bit words from RC status area, and
decode that to ASCII chars. Return the string.
readantenna --
Update antenna status from the ACU.
Synopsis
readantenna
Description
Read antenna pointing direction from hardware, and
update the RT-common.
readfrequencyfile --
Synopsis
readfrequencyfile File Addr ?Addr Addr...?
Description
-> Read a set of frequency values from a .nco file, returning
a list of NCO frequency values corresponding to the given
NCO memory addresses.
-> If any of the Addr is not found, an error is raised.
Examples
readfrequencyfile $XDIR/ch1.nco 1 2
See also
loadfrequency
readln
Activate tcl readln in current EROS window
recorder --
Manage the EROS data decoder/recorder program decodump.
Synopsis
recorder ?ion|pla? ?<OPTIONS>? ?<subcommand>?
Description
-> The recorder command is a wrapper for the Unix command line program
decodump. The recorder command should normally not be used directly,
but instead wrapped one layer deeper, by calling it via the
startdata and stopdata commands. Those commands set the options
and subcommands appropriately for EROS use. Decodump source code is
in
/kst/dsp/dsp_sce/sce2.
-> OPTIONS are "-verbose" and "mount Dirname". The Dirname must be an
absolute path name, giving the "root" directory for the decodump
output directories. For example, "/data" or "/data1". (The default
directory is defined in lib/eros_config.tcl.)
-> <subcommand>s are stop|pid|eros|nosave|save. If no subcommand is
giving, "eros" is default, meaning that the recording/norecording
mode is selected in runtime based on EROS flags. Those in turn are
controlled by startrecording/stoprecording.
-> When any of the savemodes (eros|nosave|save) is given, decodump is
started in its own window.
Examples
recorder pla pid
Returns process ID for the plasma line receiver decodump
process.PID, or return empty if no such process is running running.
recorder ion stop
Immediately kills (sends the KILL signal to) the decodump process of
the ion line receiver decodump process.
recorder -mount /data1 -verbose eros
Recording is controlled by EROS.
recorder nosave
No recording, irrespective of EROS state.
See also
restartdata startdata stopdata
remote --
Give command to a remote radar system.
Synopsis:
remote <radar list> ?<arg>...?
Description
-> Concatenate the args to a single list, Command, say.
Then take a socked connection over internet to the Messages
process at each of the radars in <radar list>, and ask it to
execute the Command, using "eval Command". Return
whatever value the "eval Command" returns.
-> In most cases, the remote command behaves in the same way
as if the Command would just have typed-in in the remote
site's console window. The return value might cause
surprises, though, and there is some room for EROS
improvements here. See rradar.
Examples
remote kir printantenna
remote "kir sod uhf" printantenna
remote ksuv stopexp Mar 15 01:00
See also
rradar
resetreceiver --
Load default values to the analog receiver chain.
This is an alias to the command
loadsetup
restartdata --
Restart correlator and recorder processes.
Synopsis
restartdata ?ion|pla|all?
Description
-> Correlator and recorder are stopped and then started with the same parameters
that were used when the programs were previously started.
-> The receiver selector is useful only at ESR. At ESR, the default is ion.
At the other sites, ion and all are equivalent to no switch, while pla causes
the whole command to be ignored.
See also
correlator recorder startdata stopdata
printdataaccess
ri --
See radarinfo
rradar --
Give command to a remote EISCAT system.
Synopsis:
rradar <radar list> ?<arg>...?
Description
-> Concatenate the <arg>s to a single list, Command, say. Then
take a socked connection over internet to the Messages
process at each of the radars in <radar list>, and ask them to
execute the Command, using "eval Command". Return whatever
value the "eval Command" returns.
-> In most cases, the rradar command behaves in the same way
as if the Command whould just have typed-in in the remote
site's console window.
-> The command is implemented in Tcl as an "internal" routine,
and is both faster and more complete than the remote
command, which calls an external (python) script. The draw-
back in the present implementation is that if the connection
is bad and no answer from the remote system is got, the
command may appear hanging (the timeout is very very long).
Examples
set x [rradar kir printantenna] ==> return ready-to-print string
set x [rr ks version] ==> return a two-element list
See also
remote uhf
rtg --
Start rtg.
Synopsis
rtg
See also
webtg
rtg2 --
Start rtg2.
rtpeek --
Read a block of values from the RT-common.
Synopsis
rtpeek ?-nonewline? ?ion|pla? ?<block name>?
Description
-> RT-common is an area of shared memory in the receiver crate
computer where EROS keeps a set of values describing the
state of the hardware and the experiment. These state
variables are grouped to "blocks", some of which can be
queried by the rtpeek command. The allowed block names are
ant,exp,dsp,tx,upar,txwg
-> If no Name is given, the list of allowed Names is returned.
By default, the command returns a ready-to-print string of
the form
x = "key1 value1 \n ?key2 value2 \n ...?"
-> If instead of printing, one wants to access some of the
values programmatically (in an ELAN file, say), one
possibility is to suppress the newlines by using the flag
-nonewlines, and convert the returned "key value key
value..." list to an array, by e.g.
array set ant [rtpeek -nonewline ant]
-> The values can then be accessed by indexing into the array
with the corresponding key, like "set A $ant(azim)".
-> The receiver selector switch ion|pla is useful only at ESR.
The default value at ESR is "ion". At the other radars,
"ion" is ignored, and if "pla" is used, the command returns
immediately with value "".
See also
rtpoke
rtpoke --
Write to the RTcommon.
Synopsis
rtpoke ?ion|pla|all? <block name> <key> <value> ?<key> <value> ...?
Description
-> The command rtpoke writes a set of values to the block Name
in the shared memory, the RTcommon, of a receiver crate
computer. Use the command "rtpeek" to find what Names are
available, then use the command "rtpeek Name" to find what
Key's belong to that block.
-> rtpoke is not intended for routine use. It is the task of
EROS to keep the RTcommon up-to-date. However, it
sometimes happens that EROS is not doing the proper job,
and as an emergency repair, you may want to poke a value to
the RTcommon interactively, or even from your ELAN file.
-> The receiver selector is useful only at ESR. The default
at ESR is "ion". At the other sites, "ion" is ignored, and
" rtpoke pla .... " does not do anything. If "all" is used
at ESR, the given set of Value's is poked both to ion and
pla RTcommons.
See also
rtpeek
runexperiment --
Start executing an experiment script (ELAN file).
Synopsis
runexperiment <Filename> <Timespec> ?<Arg>...?
Description
-> The runexperiment command starts the execution of an EROS
experiment script, an ELAN file, with all the radar's
features enabled. Use the testexperiment command to
execute the ELAN file for test purposes.
-> <Filename> is name of the experiment file. The standard
practice is to use the extension ".elan" for an experiment
script, but that is not enforced. We anyway refer to
ELAN files whether or not the file really has that
extension. EROS first searches for the given <Filename>,
which can also contain wildcards. If a unique match is
found, that is used. If there is no match and no extension
is explicitly given in <Filename>, EROS appends the extension
".elan" to the <Filename> and makes a new search. This is the
only place in EROS where such a filename manipulation is
attempted, in all other places, the pathname(-pattern)s
are used exactly as given.
-> <Timespec> gives the experiment start time, the ETIME.
Start time can be both into the future or into the past
with respect to current UTC. <Timespec> can be of any
date-time format recogized by the Tcl interpreter, and in
addition a few other formats as well. EROS feeds the
<Timespec> through the command ScanExpTime. Some of the
more common forms of <Timespec> include
12:50
"Feb 16 12:50:36" Quotes are required.
now Current GMT, truncated to full second.
fullminute Next full minute boundary.
fm Next full minute boundary.
EROS handles time with 0.1 second accuracy, so that an
expression like
"Feb 29 12:20:36.7 2008"
is the most complete <Timespec> available. Whatever format
you use, note that the <Timespec> is obligatory. If you are not
interested in when the experiment really should start, like
when you are testing some featues of the hardware, use "now".
-> Any possible remaining parameters, the Args, are made
available to the called script via the argv command. The
typical way of achieving that would be to have the following
structure in the ELAN file.
# begin typical.elan file ---
BLOCK Typical { Scan Height } {
...
commands
...
}
eval callblock Typical [argv ]
# end typical.elan file ---
This script could be executed by the command
runexp typical 12:30 cp1 298.5
if the current directory (see pwd) is the directory where
the ELAN file resides. If not, use an absolute path name.
-> To execute a script, EROS relies solely on the standart
Tcl script execution command, the "source" command.
-> When the ELAN file is given to the Tcl interpreter in EROS
Elan process (the process running in the Elan window),
the interpreter starts executing the commands in the file,
one after each other. The interpreter has no knowledge
about what commands it will meet later in the file. It
might hit some syntactic error first time only in the
middle of the next night. If any error is met, the script
terminates, and hopefully some message is output both to
the Elan window and to the Messages window. It is a
good idea to test a new scripts by running it on an offline
EROS simulator before attempting to use the script in an
actual measurement.
-> Note that it is entirely up to the commands themselves how
the execution proceeds. EROS has no explicit supervising
control over and above what the Tcl interpreter provides.
For instance, there is no way to query EROS about where in
the ELAN file the interpretation is taking place at any
given time.
-> EROS implements minimal monitoring and control facilities
by embedding into a few key commands (the SYNC, AT,
gotoblock, BLOCK, and the runexpriment commands)
certain bookkeeping and control features, on top of the
commands' manifest task. The auxiliary code does nothing
that is directly visible to the user, but helps EROS to
keep track about what is going on, and provides hooks for
the stopexperiment and gotoblock commands.
See also
argv callblock gotoblock printexperiment
stopexperiment testexperiment
s --
Send a command to the Sodankyla EROS.
See sod
ScanExpTime --
Convert a time specification to fractional seconds.
Synopsis
ScanExpTime arg ?arg...?
Description
-> This is wrapper around the standart tcl time string
reader, allowing also fractional seconds,
and allowing a +-min:sec.frac offset.
All the arguments are concatenated to a single string.
-> A few extra, single-word, TimeSpecs are also allowed.
These are
- fm, or fullm* ==> next full minute boundary
- lm, or lastm* ==> previous full minute boundary
- fs, or fulls* ==> next full second boundary
- ls, or last* ==> previous full second boundary
- now ==> previous full second boundary
- ut ==> next full 100 ms boundary
- ms ==> current time with ms resolution
- e or etim* or ex* ==> current ETIME, that is, the latest
experiment start time. If none is defined, we
raise an error.
- b or btim* or bl* ==> current BTIME, that is, the
latest BLOCK start time. If none is defined, we
raise an error.
- c or ct* ==> current CTIME (continue_at time).
-> If there are fractional seconds, the returned time
contains the fractional seconds rounded to millisec
accuracy.
-> Note that we cannot handle some of the more funny
time format supported by standard tcl [clock scan], and
some that we handle, we handle differently. As an
example of the latter, clock scan "9 aug 11" returns
seconds corresponding to 9th August, 2011, at 00:00:00, but
we return the seconds corresponding to
9th aug, current year, at 11:00:00, which is more sensible
in EROS use.
We also allow date, when the year is not used, to be given
as "20 Jun" or 20-Jun, instead of "Jun 20" (which is also
allowed).
-> In general (it is the aim that) these time formats can
be used anywhere in EROS where calender time is expected,
such as runexperiment, gotoblock, AT, at, etc.
Examples
ScanExpTime 9-Jul-2010 11:12:13.678 ==> 1278673933.678
ScanExpTime 2010-07-09 11:12:13.678 ==> 1278673933.678
ScanExpTime 9 Jul 11:12:13.678 ==> use current year as the year
ScanExpTime 11 + 1:10.5 ==> 11:01:10.5 today.
ScanExpTime fm-10 ==> 10 seconds before the next full minute boundary.
ScanExpTime lm+10 ==> 10 seconds after previous full minute boundary.
ScanExpTime tomorrow -1:10 ==> 23:58:10 today.
Sec2Date_3
Sec2Date_3 1026673186.162 ==>
2002-07-14 18:59:46.162
see --
Edit files in the (mac-only) "see" editor.
Synopsis
see ?--OPT OPTARG? PATTERN ?PATTERN...?
Description
The implied files are opened in the SubEthaEdit editor.
The command is allowed only on the local EROS console.
selectlo --
Select local oscillator frequencies.
Synopsis
selectlo
selectlo <path> <freq> (ESR and TRO UHF)
selectlo <lo> <path> <freq> (TRO VHF)
Description
The Local Oscillator (LO) frequency selection is done by actually selecting among
a set of LO units, each running on a fixed frequency.
ESR
---------------------
-> Select the first local oscillator (LO1) frequency in the
four available PLASMALINE receiver IF1 <path>s P1...P4.
-> Without parameters, the current LO1 setup is returned.
-> <path> =
P1 = U32 = 32U = U32m = U Upshifted plasmaline path from the 32m antenna
P2 = D32 = 32D = D32m = D Downshifted plasmaline path from the 32m antenna
P3 = U42 = 42U = U42m Upshifted plasmaline path from the 42m antenna
P4 = D42 = 42D = D42m Downshifted plasmaline path from the 42m antenna
-> The <path> specification using just "U" or "D" is for backwards compatibility only
and should not be used.
-> <freq> =
435.5 | 441.0 on the U** paths P1 and P3
419.0 | 424.5 on the D** paths P2 and P4
-> The <freq> can also be specified with some other formats, such as using
"H" in place of 441.0 and 424.5 (higher of the two available oscillator frequences on a given path)
"L" in place of 435.5 and 419.0 (lower of the two available oscillator frequencies on a given path)
or as an optionally signed shift from the IONLINE LO1 frequency 430 MHz, that is,
-5.5|5.5 in place of 424.5 (5.5 MHz shift down from 430 MHz)
-11.0|11.0 in place of 419.0 (11 MHz shift down from 430 MHz)
+5.5|5.5 in place of 435.5 (5.5 MHz shift up from 430 MHz)
+11.0|11.0 in place of 441.0 (11 MHz shift up from 430 MHz)
-> Note that the LO1 on both IONLINE paths I1 (from 32m antenna) and
I2 (from 42m antenna) is not in Eros control but is fixed to 430.0 MHz.
-> At ESR, none of the LO2 is under Eros control, but is fixed to 81.25 MHz.
-> Ex.
selectlo U32 435.5 ;# 5.5 up from ion line
selectlo D32 424.5 ;# 5.5 down from ion line
selectlo U42 435.5 ;# 5.5 up from ion line
selectlo D42 424.5 ;# 5.5 down from ion line
which is the default setup after Eros boot, and after an experiment start and stop
The defaults are specified in the file rxif_esr.conf, and set using loadsetup.
TRO UHF
---------------------
The TRO UHF signal path splits into two after the 14.5 MHz wide
first IF, which is from 106.5 to 121 MHz. The two branches
are called the "ION" branch and the "PLA" branch.
The ION branch covers frequency range 925.4--933 MHz, the
PLA branch covers frequence range 919.4 - 928.2 MHz.
The LO selection (LO2 selection in this case) is the following:
Path = ion|pla or 1|2
For ion
Freq = 128|130
For pla
Freq = 122|124
TRO VHF
---------------------
At VHF, both LO1 and LO2 frequency can be selected on both
of the two signal paths (I=A) and (II=B).
The LOs must first be brought under computer control
by the command
transferlo rec
* Select LO1 frequency:
selectlo lo1 I|A 290|298
selectlo lo1 II|B 290|298
* Select LO2 frequency:
selectlo lo2 I|A 78|80|82|84|ext
selectlo lo2 II|B 78|80|82|84|ext
* Without the frequency parameter, the command returns the latest set value,
e.g. selectlo lo2 B
* The default frequency for LO1 is 298 MHz, and for LO2, 84 MHz.
-> selectlo is ignored in KIR and SOD.
-> Default state:
The LO selection and control is set to default state by runexperiment and
stopexperiment commands via a call to loadsetup. The default state is
defined in a file whos name is available online via
eGet rxifconfig
Typically, this would be a .conf file in /kst/eros5/gadgetbox/etc/
This arrangement implies that if selectlo is to be used in an ELAN file,
it should normally be preceeded by the transferlo command in the file.
See also
transferlo loadsetup printreceiver
selectplad --
Select plasmaline receiver A/D input source at ESR.
Synopsis
selectplad
selectplad <A/D> <source>
selectplad <A/D> <source> <A/D> <source>
Description
selectplad is used to specify which of the four possible IF1 paths ("sources")
feeds which of the two available A/D converters of the ESR plasma
line receiver. The four IF1 signal paths are the upshifted and downshifted plasma line
path from 32m antenna, and the upshifted and downshifted plasma line
path from the 42m antenna.
-> <A/D> = AD1 | AD2
-> <source> = D32 | U32 | D42 | U42
-> Other sensible <source> names can also be used, eg 32u and u32m instead of u32.
-> Without parameters, the current setup is returned.
-> Note that both AD1 and AD2 always have __some__ source. If in the command
one or the other of the two A/Ds is not referred to, its source is unchanged.
-> The source selection is set to default state by
runexperiment and stopexperiment commands via a call to resetreceiver.
Currently, the default is to have AD1 to use D32m for its input and
AD2 to use U32m for its input, corresponding to the command
selectplad ad1 32d ad2 32u
-> selectplad has effect only if transferad is set to "rec" (this
is the default).
-> selectplad is ignored if not at ESR.
See also
resetreceiver printreceiver transferad
setacu --
Set/query ACU computer/standby mode.
Synopsis
setacu ?<state>?
Description
<state> = computer|poweron|on
standby|poweroff|off
If <state> is not given, the current <state> is returned, either
as "computer", "standby" or "fault".
setad --
Set ad
Synopsis
setad Channel ad
Examples
setad ch2 1
setattenuator --
Set overall attenuator of a reciever chain.
Synopsis
setattenuator <path> ?<attenuation>?
Description
-> The signal attenuator is located in the "IF2 box".
-> At VHF, <path> = "I" or "II".
-> At ESR,<path> is one of the following:
ad1ion|32m|i This is the ION receiver attenuator in front of AD1
ad2ion|42m|ii This is the ION receiver attenuator in front of AD2
ad1pla|iii This is the PLA receiver attenuator in front of AD1
ad2pla|iv This is the PLA receiver attenuator in front of AD2
-> At TRO UHF, <path> = I|ion or II|pla
-> Attenuator value is 0-63 (dB), higher values are silently
clipped to 63. Negative values raise an error.
-> Without the Attenuation parameter, current value is returned.
Examples
at ESR:
setattenuator 42m 16
setattenuator 32m 15
setattenuator ad1pla 9
setattenuator ad2pla 22
at UHF:
setattenuator ion 16
setattenuator pla 15
at VHF and KS
setattenuator i 15
setattenuator ii 15
setclockdelay --
Set "clock delay" for the receiver radar controller.
Synopsis
setclockdelay
setclockdelay <Delay in usec>
setclockdelay <Delay in usec> <Integrationperiod in usec> <RC start time in fractional seconds>
Description
-> The command is EROS interface to the Unix-level command
time_offset. The time_offset command has an additional
parameter, the sync pulse frequency. In EROS
implementation, that parameter is not directly available,
but instead is defined in the file eros_config.tcl, as the
variable mpv(rxrc,syncfreq).
-> Normally setclockdelay should not be given interactively,
as it is issued automatically by the tristatic pointing
commands. However, if the ppdoffset is changed
setppdoffset, this command without parameters can be used
to update the clock delay.
-> Note that the first two forms of the command require that
the integration period and receiver RC starttime have
already been defined in EROS.
Examples
setclockdelay
setclockdelay 3300.2
setclockdelay 2300 10000000 976543210.275
See also
pointrrange pointrheight pointgeographic
setppdoffset
setesrtx --
Set/query ESR transmitter state.
Synopsis
setesrtx ?<state>?
Description
-> <state> = tx | sb(standby) | bh(blackheat) | off | reset
-> If <state> is not given, the current state is returned, either
as "tx", "standby" "blackheat" or "off".
setfrequency --
Set digital receiver channel's tuning frequency (NCO frequency).
Synopsis
setfrequency ?<OPTIONS>? <frequency> <channels>
setfrequency ?<OPTIONS>? <receiver> <frequency> <channels>
Description
-> The setfrequency command sets the numerically control oscillator
frequency on one or more receiver channels to the given value. The
command takes effect immediately, but might be also immediately
overwritten if the receiver radar controller is controlling the NCO
frequencies, see loadfrequency.
-> <receiver> has effect only at ESR, where it can be either "ion" or
"pla", for the ionline and plasmaline receiver, respectively. If
the selector is omitted, "ion" is used.
-> <channels> is a string of channel identifiers. For example
ch1
ch1,3
ch1 ch3
-> <frequency> must be in MHz, and is checked for sensible bounds.
-> OPTIONS
-T|-test: No actual loading, the value to be loaded is returned.
This value may differ from the given value by at most 1.7 mHz,
due to native NCO frequency granularity, or by at most 7.0 mHz,
if the -E flag (below) is in effect.
-E: Enforce ESR exciter-compatible frequencies. This is the default
behaviour at ESR. The ESR exciter has four times coarser
frequency granularity than the NCO, and this options forces the
given NCO frequency to the nearest available exciter frequency.
-u|-uncorrected: Enforce NCO-native frequencies.
From Autumn 2015, this is the default behaviour at non-ESR
sites.
-v: Verbose loading, showing the load table with 0.1 mHz frequency
accuracy.
Examples
U: setfrequency ch1 ch2 11.75
U: setfrequency ch1,2,3 10.5
U: setfrequency -T ch1 10.7 ==>
10700000.0007 Hz (native)
E: setfrequency ion ch1 11.25
E: setfrequency pla ch1 11.25
E: setfrequency -T ion ch1 10.7 ==>
10699999.9937 Hz (native 10700000.0007 Hz)
See also
loadfrequency
setpanelpath --
Set receiver paths for panels at an VHF.
Synopsis
setpanelpath ? Path ?
Description
-> Path is "allA" or "allB" or "split".
-> Without argument, return the current path.
-> The command is ignored at non-VHF sites.
setpolariser --
Set polarizer phase and amplitude
Synopsis
setpolariser
setpolariser <PHA> <AMP>
setpolariser <PHA> <AMP> <FLAG>
Description
-> Set the polariser "phase" and "amplitude" parameters.
The command has effect only in Kiruna and Sodankyla.
-> Without parameters, the polariser setting is computed
by EROS based on latest tristatic pointing command
such as pointrheight, and uses the site's polariser
offsets. Typically, setpolariser command would be
placed immediately after the pointing command in an ELAN
file.
-> PHA must be between 0 and 409
-> AMP must be between -127 and +127.
-> If FLAG is set to 0, do _not_ make any polariser offset
correction. If flag is missing, or is set to anything
else than 0, the offset correction is made.
-> The command currently achieves nothing because
polarizer HW in KIR and SOD is disconnected.
See also
checkpolariser getpolariser pointrheight printantenna
setppdoffset --
Modify the geometry-based pulse propagation delay (PPD) by an offset.
Synopsis
setppdoffset ?<microsecs>?
Description
Set the value of the EROS PPDOFFSET variable. Nothing
else is done by this command. The PPDOFFSET variable is used
by the setclockdelay command whenever that is executed,
typically in connection of a tristatic pointing command such as
pointrheight.
Without the <microsecs> parameter, return the current value.
See also
pointrheight printantenna setclockdelay
settrackinginterval --
Set/get tracking interval
Synopsis
settrackinginterval ?<ms>?
Description
-> In KST systems, where tracking of celestial objects is not in
antenna hardware, the tracking is done by repeatedly giving
pointing commands at regular intervals. That interval is called the
tracking interval. When EROS is booted, it is initialized to 2000
millisec.
-> Change of tracking interval takes effect next time the tracking is
started using the trackcelestial command.
-> At ESR, the tracking is done smoothly by hardware, and the
trackinginterval is not used. The command can still be given at ESR
also, but has no effect.
See also
trackcelestial
settrackingoffset --
Set/get tracking azimuth and elevation offsets.
Synopsis
settrackingoffset ?-a <Azim Offset>? ?-e <Elev Offset>?
Description
Set or query tracking offset in degrees, for azimuth and/or elevation.
Examples
settrackingoffset
==> return the two-element list {AzOff ElOff} of current offsets
settrackingoffset -a 1.1
==> set AzOff to 1.1 degr, return {AzOff ElOff}
settrackingoffset -e -1.2
==> set ElOff to -1.2 degr, return {AzOff ElOff}
settrackingoffset -a 1.1 -e -1.2
==> set AzOff to 1.1 degr aand ElOff to -1.2 degr, return {AzOff ElOff}
See also
trackcelestial settrackinginterval
sexa2dec --
Convert from sexadecimal notation to decimal notation.
Synopsis
sexa2dec SexaSpec
Examples
sexa2dec 10:30:45.2 ==> 10.51255556
sexa2dec {-3 45 17} ==> -3.75472222
sexa2dec {0 -30} ==> -0.50000000
See also
dec2sexa
showantenna --
Synopsis
showantenna start ?StartTime? ?-d DwellTimeSec?
showantenna stop ?now?
showantenna ?print?
Description
- Start executing a hardcoded 4-position antenna motion loop.
- The pointing commands in the loop are given using pointdirection.
The command is intented for demonstrating antenna motion for
visitors.
- If -d DwellTimeSec is not given, 60 sec is used.
- Use "showantenna stop" to stop the loop, and also to cancel
a not-yet-started but scheduled show.
- Currently, the loop is defined only for TRO UHF and for SOD.
Examples
showantenna ==> show the loop commmands and the start time
showantenna stop
showantenna start 12:30 -dwell 30
Version
10-Oct-2009
sideraltime --
Find sideral time.
Synopsis
sideraltime ?<site>|<longitude spec>? ?<UTC spec>? ?-hms?
Examples
sideraltime ==> LMST for current site, now (as decimal hours)
sideraltime K ==> LMST for Kiruna site, now (as decimal hours)
sideraltime S -hms ==> LMST for Sodankyla, now, as HH:MM:SS.s
sideraltime 10:45:15 ==> LMST for local site, at 10:45:15 UT
sod --
Send a command to the Sodankyla EROS.
Synopsis
sod ?<arg> ...?
s ?<arg> ...?
Description
The command is a shorthand for rradar sod ?arg arg ...?
See also
remote rradar
startdata --
Start data access by starting both correlator and recorder.
Synopsis
startdata ?<rec>? <CorrFile> <Expid> <Iper> ?<Ant>?
Description
-> Receiver specification <rec> can be -ion|ion|-pla|pla. The receiver
specification is useful only at ESR. At other sites, "ion" implies the
standard (and only) receiver, while "pla" causes the whole command to be
ignored. At ESR, if <rec> is not specified, "ion" is assumed.
-> <CorrFile> is name of the correlator ".fil" file. In an ELAN file, use
absolute path name for the file.
-> <Expid> is a string, which should confirm to the "experiment naming
convention", though this is not enforced yet. It is recommended to form
the Expid by using the expid command.
-> <Iper> is integration time. If no unit is given, the default is
microseconds. If unit is embedded, also seconds are accepted, so "6.40s",
"6400000" and "6400000us" and are equivalent. <Iper> should be an integer
multiple of 10 ms.
-> <Ant> is the "data source", like "32m" or "uhf". This is useful only
with ESR ion line receiver where it can be 32m and 42m. In all other
cases, the correct value is silently enforced. The <Ant> parameter is
used by the recorder ("decodump") to form the data file names, but EROS
can not check that the given <Ant> actually is the physical data source
at any given moment of time.
-> The printdataaccess command can be used to show the state of the
data access.
Examples
startdata ion $CORR "kst0 ipy_ip2_4.2l_CP" 6400000 42m
set CORR /kst/exp/tau1/tau1_u.fil
set Expid [expid tau1 cp3 1.30u ei]
startdata $CORR $Expid 5000000
startdata $CORR $Expid 5.0s
See also
correlator expid printdataaccess recorder restartdata
startradar --
Schedule radar controller start.
Synopsis
startradar <time spec> ?<skipping step>?
Description
-> <time spec> is either a UTC specification like "12:00:00.123456" or
the keyword "E" (or EXPSTART or ETIME), or any other of the time
expressions recognized by EROS, see ScanExpTime. The <time spec>
can be given with microsecond granularity.
-> <skipping step> is in fractional seconds, with 10 ms resolution.
If <skippin step> contains an embedded unit, seconds (s) and
microsecs (us) can be used, as e.g. "6.45s" or "6450000us".
The 10 ms resolution is changed behaviour (Oct 2016). Earlier,
the skipping period in EROS had to be an integer multiple of 100 ms.
==> In the normal case <skipping step> should be set equal to the
experiment's integration period. If this is not done, synchronization
to the original experiment start time may be lost when the
experiment has to be restarted.
Integration period can now be specified with 10 ms granularity,
corresponding to the 10 ms periodicity of the RC restart synch signal.
This is changed behaviour (Oct 2016), earlier EROS required the
integration period to have 100 ms granularity.
-> If <skipping step> is not given, the start is arranged to happen as
soon as possible, but never earlier than at max{<time spec>, NOW+EPS},
where NOW means current UTC and EPS is a radar-system-specific delay,
which varies from 0.2 sec (H,K,S) to 2.0 sec (ESR). Also, if <skipping
period> is not given, the start is always forced to a 10 ms boundary.
-> The purpose of the startradar command is to schedule generation of a
trigger pulse from the radar's microsecond-scale timing hardware, the
TrueTime board, to the radar controllers. To that end, startradar
writes a time specification, which we call here the Triggertime, into
the board's time comparison register. When UTC exceeds the Triggertime,
the board sends a trigger pulse to the site's radar controllers, all of
them. Only those radar controllers which are in "armed" state when the
pulse arrives will start executing. See the commands armradar and
loadradar. The non-armed radar controllers ignore the trigger pulse.
-> The start pulse also synchronizes the 100 Hz restart pulse train to the
Triggertime (and hence also to the given <time spec>).
-> In multistatic measurement, where the remotes perform PPD correction, by
shifting the restart pulse train from by PPD from its "standard" position
at 10 ms boundaries, care need to be exercised. In the tristatic case,
the transmission site probably should be synchronized to the 10 ms
boundaries.
-> The purpose of the <time spec> and <skipping period> parameters is to
allow startradar to compute the Triggertime as
Triggertime = <time spec> + N*<skipping step>,
where N is the smallest non-negative integer such that Triggertime is
at least EPS into the future.
-> Note that <time spec> can be in the past or in the future, but
Triggertime will always be in the future. The Triggertime will never
be earlier than <time spec>.
Examples
ri @iper 6.45s
startradar 12:00:06.123456 6.45
startradar 13:00 6.45s
startradar ETIME 6450000us
startradar E @iper
startradar now
See also
armradar loadradar stopradar ScanExpTime
stopdata --
Stop data access by stopping both correlator and recorder.
Synopsis
stopdata ?ion|pla|all?
Description
The decodump and lag_wrap processes are killed. At ESR,
if the option "all" is used, those two processes are killed
both in the ion-line and the plasma-line receivers.
See also
correlator recorder restartdata startdata
stopexperiment --
Stop an expriment.
Synopsis
stopexperiment ?<flags>? ?<time spec>?
stopexperiment cancel
Description
-> Stopping an experiment involves both terminating the execution of
the experiment script and stopping various hardware and software
subsystems. Normally, you should use
stopexperiment
to stop immediately, or something like
stopexperiment "31-Jul 01:30:00"
to schedule a stop for a specified time. Expect these basic
command forms to do "the right thing".
-> For exceptional cases, more control is provided by the <flags>:
-terminate Only terminate the execution of the
experiment script.
-all Normally, the transmitter radar controller is
left running. This option causes it to be
stopped, too.
-> Use
stopexperiment cancel
to cancel a scheduled stop. (A scheduled stop is shown by
the printexperiment command.)
See also
runexperiment testexperiment printexperiment
stopradar --
Immediately stop a radar controller.
Synopsis
stopradar ?rec|trans|ion|pla|all?
Description
Stopradar command stops immediately a radar controller.
-> "ion is equivalent to "rec"
-> " stopradar pla " is ignored at non-ESR sites.
-> " stopradar trans" is ignored at KIR and SOD.
-> Without arguments, stops only the receiver R/C,
except at Heating, where both R/Cs are stopped.
Examples
stopradar
stopradar rec
stopradar trans
stopradar all
stopradar pla
See also
armradar loadradar startradar printexperiment
Last modified
20-May-2009 Jm
stoptracking --
Stop the flow of tracking point commands.
Synopsis
stoptracking ?-point|-nopoint?
Description
With "-point", at ESR, give a "moveelevation 0" command to actually
with "-async" (the default), with the asynchronous aSend.
subl --
Edit files in the "sublime text" editor.
Synopsis
subl ?<OPTIONS>? <pattern>|<filename>?:<linenumber>? ...
Description
The implied files are opened in the Sublime Text editor.
The command is allowed only on the local EROS console.
sweepcelestial --
Move antenna slowly past a celestial point.
Synopsis
sweepcelestial ==> start a predefined sweep, do not save azel data
sweepcelestial save ==> start a predefined sweep, save azel data
sweepcelestial abort ==> abort current sweep
sweepcelestial info variable1 ?variable2 ...?
Description
This command is designed for antenna pointing direction
calibration. See the antenna calibration ELAN file
for examples of actual usage.
See also
definesweep celdirection pointcelestial trackcelestial
SYNC --
Synchronize commands to UTC in a running experiment.
Synopsis
SYNC ?-silent? <time spec>
Description
-> <time spec> = <number>?s|ms? If the unit specifier is missing, "s" is
assumed.
-> <number> can be seconds (default) or milliseconds, with embedded unit.
<time spec> is silently rounded to millisecond accuracy.
-> The purpose of a SYNC is to control accurately--within a few
milliseconds, with millisecond resolution--when the first command after
the SYNC will be executed, with respect to the BLOCK start time.
-> Before the first SYNC in the elan file, and between the SYNC commands,
elan file commands are executed sequentially as fast as possible. But EROS
has no control of how long the commands take, thus the second and
subsequent commands after the SYNC will take place at unpredictable
times.
-> This implies that any command that must happen at a known instant of time
must be placed after its own SYNC.
-> In the SYNC routine, first the <time spec>--which can also be negative
--is added to the current CTIME (the "continue at" time, shown in the
printexperiment command). Then the experiment is suspended until UTC
becomes greater than or equal to the CTIME. The experiment is suspended by
yielding the thread of execution to the Tcl event loop. Thus the Elan
process where the expriment is executing will still be responding to Tcl
events during the SYNC.
The following pseudocode summarises SYNC T implementation.
------
SYNC T
------
|
-----------------
CTIME = CTIME + T
-----------------
|
------------------------
sleep until UTC >= CTIME
------------------------
|
------
return
------
-> It can happen that at the instant when a SYNC is encounted in the elan
file, the UTC already is greater than the CTIME would be after the
SYNC. In that case, the SYNC is ignored except that the CTIME is
still incremented by the <time spec>. This is called "skipping" in EISCAT
parlance.
-> CTIME is initialised to the experiment starttime ETIME by the
runexperiment command. A gotoblock command resets the CTIME to the
specified block starttime,the BTIME. BTIME is initialized to ETIME at
expriment start.
-> To syncronize commands directly to UTC, use the AT command.
-> The SYNC command has effect only in an elan file.
-> The flag -silent turns off some messages, like warnings that a late
SYNC has been skipped.
-> Normally, a well-behaving experiment should spend most of its time in the
SYNC and AT commands. At these times, and only these, it is possible
to affect an external, asynchronous, "context switch" via a
stopexperiment, callblock, or gotoblock command. Those command to
the Elan process can be given from EROS Console (local or remote) at any
time, but they are activated only when the thread of execution of the Elan
process is in the event loop.
See also
AT
tarlan --
Compile radar controller (.tlan) file.
Synopsis
tarlan ?args...?
Description
The command is a wrapper around the tarlan_<xxx>
Unix-level compiler, appropriate for the system in question.
Example
tarlan -f /kst/exp/bella/bella-u.tlan
testexperiment --
Execute an ELAN script, without recording data.
Synopsis
testexperiment ?<OPTIONS>? <Elanfile> <Starttime> ?<Arg> <Arg> ...?
Description
-> Execute an expriment file, but
* Do not record any data,
* Do not copy expriment files to info directory,
* Do not make any logbook entries,
* Do not make any "eroslog" entries, but write
corresponding entries to "erostestlog" instead,
* By default,do not access the antenna. Use the
option "-useant" if antenna access nevertheless
is required.
-> OPTIONS:
-useant Access antenna normally, unless
inhibited by inhibitantenna.
-noant Block access to antenna. This is default.
-> The EROS commands that are disabled due to
testexperiment are disabled "globally" in the EROS
system, that is, even when they are given interactively.
-> The controlling flags are cleared when the experiment is
stopped. A runexperiment command always clears the test
flags.
Examples
[test] tau1 now
[test] -useant tau1 10:30 cp3 EI 295.5
See also
runexperiment
testrecording --
Set the .flag directory and put "Junk" the proper file.
Synopsis
testrecording ? on|off|?|query ?
Description
- For example BASEDIR '/' EXPNAME @ SOURCE '/' .flags '/' yyyymmdd_hh
in the yyyymmdd_hh file it will be one word Junk.
- Also if enablerecording in testexperiment is done, "on"
will be the default state.
- The command manipulates the "nosave" flag in rtcommon's dds block.
tic --
Start an interval timer.
Synopsis
tic ?-c?
Description
The interval timer uses [clock microsec], or, with option
-c, [clock clicks], to estimate an interval. tic resets
the interval start to current value. toc reads out the
currently elapsed interval since last tic. The standard
Tcl documentation about the [clock] options.
See also
toc
timestamp --
Format a Unix-type seconds value to a string.
Synopsis
timestamp ?-3? ?<NO-FLAGS>? ?<time spec>?
timestamp ?<FORMAT>? ?<time spec>?
Description
-> <time spec> is either fractional seconds (such as returned from
ScanExpTime), or some of the keys "now|E|B|R|T|C".
E means experiment start time, B means block start time,
C means continue_at time, R means receiver radar
controller starttime, T means transmitter radar
controller start time.
If <time spec> is not given at all, "now" is assumed.
A special case is <time spec> == -1, which several EROS time commands
return as an error indicator. If <time spec> < 0, timestamp
returns an empty string, but gives no error.
-> -3: This flags causes 3 decimal places in the fractional seconds.
Default is use 1 decimal place.
NO-FLAGS
-noyear: Do not print year
-nodate: Do not print day-mon-year
-nofrac: Do not print fractional part of seconds
If any of the NOFLAGS is used, FORMAT must not be used.
FORMAT
-dyhms ==> DD-MON-YEAR HH:MM:SS
-dyhms1 ==> DD-MON-YEAR HH:MM:SS.f
-dyhms3 ==> DD-MON-YEAR HH:MM:SS.fff
-dhms ==> DD-MON HH:MM:SS
-dhms1 ==> DD-MON HH:MM:SS.f
-dhms3 ==> DD-MON HH:MM:SS.fff
-hms ==> HH:MM:SS
-hms1 ==> HH:MM:SS.f
-hms3 ==> HH:MM:SS.fff
If any of the FORMATs is used, NOFLAGS and -3 must not be used.
Examples
if x == 1280319306.573, then
-> timestamp $x
==> 28-Jul-2010 12:15:06.6
-> timestamp -3 $x
==> 28-Jul-2010 12:15:06.573
-> timestamp -3 -nod $x
==> 12:15:06.573
-> timestamp -hms1 $x
==> 12:15:06.6
See also
ScanExpTime TimeStamp Utime
HMS DHMS DYHMS
[HMS3] [DHMS3] [DYHMS3]
[HMS6] [DHMS6] [DYHMS6]
TimeStamp --
Format a seconds value to a string.
Synopsis
TimeStamp ?<OPTIONS>? ?<time spec>?
Description
-> See timestamp for a description of <time spec> and <OPTIONS>.
-> Note that TimeStamp executes in the current
computer while timestamp will refer <time spec> to the
computer which runs the EROS Messages and Elan processes.
See also
timestamp HMS
tle --
Manage TLE-based satellite position calculations.
Synopsis
tle init
tle reset
tle site ?SITEID?
tle site SITENAME LAT LON ALT
tle read FILENAME ?-colloq|-internat|-norad? TAG
tle read2ln LINE1 LINE2
tle par TLEHANDLE
tle print TLEHANDLE
tle free TLEHANDLE
tle celpos ?-s SITEID? TLEHANDLE ?UTC_SPEC?
tle dir ?-dt EPS? ?-s SITEID? TLEHANDLE ?UTC_SPEC?
Description
The tle command provides a wrapper over EROS wishe's built-in etle command. The
wrapper executes the etle commands in the EROS central engine process (Messages),
where all EISCAT sites are predefined, so an explicit INIT is not needed. Also,
the wrapper allows explicit site names instead of site handles to be used.
SUBCOMMANDS
-> INIT clears all TLE and site definitions, and (re-)creates EISCAT
site definitions. This is called automatically at EROS boot-up, and
at the start of an experiment.
-> RESET frees all the TLE handles, and also resets the handle generator so
that the next invocation of READ or 2LN returns handle "tle0".
-> SITE returns an old, or creates a new, observation location. All EISCAT
sites are pre-defined in EROS at boot time, and need not be defined
explicitly.
* With no parameters, SITE returns the EROS site's lat, lon and altitude.
* With one parameter, which must be a site name or a site handle, SITE returns
lat, lon and altitude of that site.
* With four parameters, SITE defines (or redefines) a site, and returns
a SITEHANDLE. Afterwards, the site can be referred to either by the name
or by the handle.
The predefined sites UHF, KIR, SOD, ESR, VHF and HOT cannot be redefined.
-> READ reads a single TLE definition from a file. The required
record is specified by the TAG, which can be either the
colloquial name, the international designator, or the
Norad catalog number. READ returns a TLEHANDLE which can be used in other
subcommands.
-> READ2LN picks a TLE from two strings LINE1 and LINE2 and returns TLEHANDLE.
-> PAR returns (most of) the TLE record fields in a
list of type {name value name value ...}
-> PRINT returns (most of) TLE record fields as a ready-to-print string.
-> FREE frees a a TLE record's internal storage.
-> CELPOS returns the apparent RA and declination of the object
for the given time, at the given site. If the observing site is
not specified with -s SITEID, the current EROS site is used.
The returned RA and declination refer to the epoch J2000 and do not
contain refraction correction. (Thus, they can be directly given to the
EROS pointcelestial and celdirection commands.) The output format
can be controlled using options -dec (==> decimal hours and decimal degrees),
-deg (==> decimal degrees) and -sexa (==> sexadecimal triplets).
-> DIR returns azimuth, elevation and range of the object for
the specified time and specified site. If time is not specified,
"now" is assumed. If observing site is not specified using -s SITEID,
the current EROS site is used. The returned azimuth (degr) and elevation (degr)
do not contain refraction correction. (This is in distinction to some other
programs like pyephem, which make refraction corrections by default.)
* With option -dt EPS, DIR also returns the rate of change of azimuth, elevation
and range, evaluated numerically using the given time step EPS in seconds.
The rates of change are in degrees per second and kilometres per second, respectively.
* With option -celpos, DIR also returns RA and declination.
PARAMETERS
-> SITEID must be either a SITEHANDLE as returned by the site-defining command
tle SITE, or a SITENAME. The SITENAME is either one of the pre-defined EROS
radar names UHF|VHF|KIR|SOD|ESR|HOT, or is a SITENAME used in the site-defining
command tle SITE.
-> LAT is latitude in degrees, LON is longitude in degrees, with
eastern longitudes positive, ALT is altitude in meters.
-> FILENAME is name of a file containing TLE specifications in
the Norad format.
-> TAG is used to pick a special TLE record from the file FILENAME,
and must correspond to the tag type given by the option
-c|-i|-n. If the option is not given, -c (colloquial name, the one
given on the "line0" of the TLE specification), is assumed.
In all cases, the given TAG must match exactly.
-> LINE1 and LINE2 are the two lines of the TLE specification.
-> The TLE_HANDLE is a string of the form "tleN", where N is
increasing for each invocation of READ or READ2LN.
-> UTC_SPEC is either any of the date-time specifications recognized by
ScanExpTime, or is "-sec SECONDS" where SECONDS is seconds from
1 Jan 1970.
Example
To compute ENVISAT azimuth and elevation at TRO UHF, get the newest TLE file
containing ENVISAT from, e.g. CelesTrak web site (http://celestrak.com).
One can use the Unix curl command from EROS console via Tcl exec command:
exec curl http://celestrak.com/NORAD/elements/resource.txt > resource.txt
and use tle READ to get the ENVISAT TLE record from the resource.txt file
set envis [tle read resource.txt -c ENVISAT].
Or, one may use tle READ2LN by first copying ENVISAT info to variables
set line1 "1 27386U 02009A 10319.91772222 .00000026 00000-0 23439-4 0 6229"
set line2 "2 27386 98.5352 24.9720 0001120 100.4056 259.7247 14.37466626455470"
set envis [tle read2ln $line1 $line2]
Check the TLE (especially, its epoch) using tle PRINT
tle print $envis
==>
noradnum 27386
designator 02009A
epoch 10319.91772222
epoch_ymd 2010,11,15.91772222
inclination 98.5352
node_ra 24.9720
eccentricity 0.0001120
argumentofp 100.4056
meananomaly 259.7247
meanmotion 14.37466626
period_min 100.1762
Compute azim, elev, range, azim rate, elev rate and range rate, using
tle dir -dt 1 $envis 1-Dec-2010 9:25
==>
139.342 47.320 1012.909 0.5157 -0.1959 2.6145
toc --
Stop an interval timer.
Synopsis
toc ?-c|-v?
Description
Stop the interval timer started with tic, and output
the interval, in fractional seconds. This is basically for timing a
command. With -c, return the number of [clock clicks] instead
of microsecs. With -v, first print the start and stop values and
the interval length of the microsec timer, then return the
interval length in fractional seconds.
Examples
tic; printant; toc ;# in fractional seconds
tic; printant; toc -v ;# in fractional seconds, verbose output.
tic -c; printant; toc -c ;# in clicks
See also
tic
trackcelestial --
Track a celestial object
Synopsis
trackcelestial <name> ?<RA> <declination>? ?<start time>? ?-quiet? ?-a <azim off>? ?-e <elev offs>?
Description
-> The epoch of <RA> and <declination> must be J2000.0.
-> Instead of using braces to group the <RA> and <declination>, one can
also use comma-separated lists as for example
trackcelestial cas-a 23,23,28 58,45,14
To specify negative declination, use e.g.
-10,40,50 or {-10 40 50}.
In all cases, sexadecimal units are used.
-> If <RA> and <declination> are not specified, <name> must refer to a
known celestial source. Use the command celsource to list
available sources. The sources are defined in the file
eros<version>/lib/celestial_sources.tcl. If <RA> and <declination>
are specified, <name> is still required, but is not used, so any
string will do.
-> For tracking start time, any valid Tcl time format can be used (see
Tcl documentation for "clock"). If <start time> is not specified, or
the keyword "now" is used, tracking is started immediately. If the
<start time> is in the future, antenna is immediately pointed to the
position where the source will be at the <start time>, but actual
tracking starts only at the given <start time>.
-> At KST, the tracking is done by generating a stream of pointing
commands. At ESR, tracking relies more on antenna hardware, using
the internal Track-Object command of the antenna control system.
-> During tracking, if the flag "-quiet" is not set, the EROS Vme
window shows information about the generated pointing stream. For
example, the line
15:11:04.0 240.24 (600.17) 76.90 (78.35) 1989
shows the pointing instant, pointing azimuth, readback azimuth,
pointing elevation, readback elevation and the measured time
interval between two pointing commands. The last value should not be
far away from the tracking interval (see the command
settrackinginterval). Both the given az,el and the readback az,el
try to compensate for antenna pointing offsets, so that the
displayed values refer to the antenna optical axis, rather than to
values given to, and read back from, the antenna control hardware.
-> At all sites, tracking of "planets" (the nine planets and sun and
moon), is done by updating the RA and declination of those objects
every now and then.
-> To display antenna info when trackcelestial is active, use the
command printcelestial, rather than printantenna.
-> The azimuth and elevation offsets <azim off> and <elev off> are in
decimal degrees. The offsets will be added to the source position.
Default offsets are zero. If you want to keep the current offset,
use "" or "." as the parameter to -a or -e.
The tracking offsets are cleared to zero by runexperiment and
stopexperiment commands. At any time the offsets can be changed
by the command settrackingoffset.
-> The status of the tracking is displayed by printcelestial.
Examples
trackcelestial cas-a
trackcelestial jupiter 10:30
trackcelestial my* {23 23 28} {58 49 14} "Jan 11 12:30:00"
trackcelestial moon -a 1.25 -e -1
See also
stoptracking settrackinginterval pointcelestial
printcelestial settrackingoffset
trackgalactic --
Track a celestial object using galactic coordinate system.
Synopsis
trackgalactic ?<name>? ?<longitude> <latitude>? ?<start time>? ?-quiet?
Examples
trackgalactic Pos1 {345 23 28} {58 49 14} "Jan 11 12:30:00"
Notes
-> The epoch of Latitude and Longitude must be J2000.0.
-> Instead of using braces to group the latitude and longitude one can
also use comma-separated lists, as for example
trackgalactic Pos1 345,23,28 58,45,14
To specify negative galactic latitude, use e.g. -10,40,50
or {-10 40 50}. In all cases, sexadecimal units are used.
-> For tracking start time, any valid Tcl time format can be used (see
Tcl documentation for "clock"). If <start time> is not specified, or the
keyword "now" is used, tracking is started immediately. If the
starttime is in the future, antenna is immediately pointed to the
position where the source will be at the <start time>, but actual
tracking starts only at the given <start time>.
-> At KST, the tracking is done by generating a stream of pointing
commands. At ESR, tracking relies more on antenna hardware, using
the internal Track-Object command of the antenna control system.
-> During tracking, if the flag "-quiet" is not set, the EROS Vme
window shows information about the generated pointing stream. For
example, the line
15:11:04.0 240.24 (600.17) 76.90 (78.35) 1989
shows the pointing instant, pointing azimuth, readback azimuth,
pointing elevation, readback elevation and the measured time
interval between two pointing commands. The last value should not
be far away from the tracking interval (see the command
settrackinginterval). Both the given az,el and the readback az,el
try to compensate for antenna pointing offsets, so that the
displayed values refer to the antenna optical axis, rather than to
values given to, and read back from, the antenna control hardware.
-> To display antenna info when trackgalactic is active, use the
command printcelestial, rather than printantenna.
See also
stoptracking settrackinginterval pointcelestial
printcelestial trackcelestial
transf_galact --
Transform Ra/Dec <--> galactic Lat/Long.
Synopsis
transf_galactic Dir Long Lat Ra Dec
Description
Dir is 0 for Ra/Dec --> Lat/Long
Dir is 1 for Lat/Long --> Ra/Dec
transferad --
Transfer plasma A/D source switching control RC<-->REC.
Synopsis
transferad rec|eros | rad|rc
Description
Transfer plasma AD control from radar controller
("rad" or "rc") to EROS ("eros" or "rec"), and the other way round. Only
when the control is on EROS, does the EROS selectplad
command have on effect. Default control source is EROS. Setting is reset
to default at expriment start and stop via resetreceiver.
The command is only allowed at ESR.
Examples
transferad rec
transferad rad
See also
printreceiver resetreceiver selectplad
transferlo --
Transfer local oscillator control RC<-->REC.
Synopsis
transferlo rec|rad
Description
Transfer local oscillator (both LO1 LO2) control from radar controller
("rad") to EROS ("rec"), and the other way round. Only
when the control is on EROS, does the EROS selectlo
command have on effect.
Examples
transferlo rec
transferlo rad
Note
The command is only allowed at VHF.
See also
selectlo
transfernoise --
Transfer noise control REC<-->RC (OBSOLATE)
Synopsis
transfernoise rad
Description
-> The command
transfernoise rad
is allowed but has no effect.
-> Noise injection is currently permanently under R/C control.
Therefore,
transfernoise rec
results in an error.
txpower --
Get tx power from the local RT-common.
Synopsis
txpower
u --
Send a command to the UHF EROS.
See uhf
uhf --
Send a command to the UHF EROS.
Synopsis
uhf ?<arg>...?
u ?<arg>...?
See also
remote rradar
upar --
Set and query EROS user parameters.
Synopsis
upar Index ?Value?
upar Index Oper ?Value?
upar alias Index Name
Description
-> The "user parameters" (upars) are a set of MAX_UPAR
real-valued variables that are known globally in EROS. The
same upars are visible in ELAN files and the the EROS
console, and thus provide a way to manipulate the parameters
of a running expriment file interactively. For example, if a
upar is used for the common volume altitude in the pointing
commands that form an antenna scan, the scan's altitude can
be changed by changing interactively the upar's value. The
upar values are saved in the data dump parameter vector,
d_parbl, in locations 43 to 62.
-> The present implementation of user parameters hides the
parameters from direct access. They are not visible as
variables in EROS but must be read and written via the
upar command.
-> Index can be 1 .. MAX_UPAR, or can be "all", where the
MAX_UPAR is the value defined in /kst/dsp/include/kstsys.h,
(currently 20). Thus one way to find out at run-time the
value of MAX_UPAR is to use the command "length [upar all]".
-> The command "upar Index" returns current value of upar(Index).
-> The command "upar Index Value" sets upar(Index) to Value.
-> The command "upar Index ++" increments upar(Index) by one.
-> The command "upar Index OP Value" perform a C-languge type
modification to upar(Index), with OP "+=" | "-=" | "*=" | "/=".
-> The command "upar alias Index Name" attaches a symbolic
name to a upar Index, so that the Name can be used
anywhere where a numerical Index would otherwise go. The
Name is for online use only.
-> EROS resets all upars to zero at EROS boot, and at
experiment stop.(This behaviour is recent, initially, EROS
did not reset the upars.)
-> EROS keeps the current values of upars in the RTcommon, and
only there. The RTcommon is a shared memory area, physically
in the receiver crate computer. At ESR, this requires special
considerations, because at ESR there are two receiver crate
computers used by EROS, and two data accesses. The
correlator program running in the crate computer that
takes the upars (as well as other parameters) from its local
RTcommon, and attaches them to the measured data. So, at
ESR, two RTcommons must be available, one for each data
access, ION and PLA. At ESR, one could have separate sets of
upars for both receivers, but that would make the already
cumbersome notation that is used to manipulare the upars
even more confusing. Therefore, only a single set of
MAX_UPAR upars is made available at ESR also. EROS tries to
ensure that the upars in ION and PLA RTcommons are idential.
If the user assigns upar a value, the value is copied to
both RTcommons. But when a value is read, even when doing a
read-modify-write, it is read only from the ION RTcommon.
-> One possible source of confusion is that for most purposes,
the command "upar Index" returns the value as a string
representation of the internally kept floating point value,
with four decimal digits. This holds even when the value
actually is an integer. Therefore, the following does
not succeed:
set Arr(1) 111
upar 5 1
puts $Arr([upar 5]) ==> "Arr(1.0000)": no such element
The remedy in this case would be to perform an explicit
rounding
puts $Arr([expr round([upar 5])])
Examples
upar 2 6.7 ==> set upar(2) to 6.7"
set x [upar 2] ==> set x to current value of upar(2)"
upar 2 ++ ==> increase upar(2) by 1"
upar 2 -= 3.45 ==> decrease upar(2) by 3.45"
upar all -1 ==> all upars are set to -1.000.
upar alias 2 MyU ==> "upar MyU" is now synonym to "upar 2"
upar MyU += 3.45 ==> increase upar(2) by 3.45.
uptime --
Time since latest EROS boot.
Synopsis
uptime ?-verbose?
Utime --
Return current UTC, as fractional seconds, rounded to millisec.
Synopsis
Utime
v --
Send a command to the VHF EROS.
See vhf
version --
Print out EROS version info.
Synopsis
version ? FORMAT ?"
Description
Return version info.
FORMAT = date | number | long | seconds
vhf --
Send a command to the VHF EROS.
Synopsis
vhf ?<arg>...?
v ?<arg>...?
See also
remote rradar
vi --
Edit files in the "vi" editor.
Synopsis
vi -OPTIONS PATTERN ?PATTERN...?
Description
The implied files are opened in the vi(m) editor, in a separate
xterm window. The command is allowed only on the local
EROS console.
webtg --
Start webtg.
Synopsis
webtg ?Options? ?Command?
Description
-> Execute the script "/kst/remtg/webtg", which start (or stops)
the web-enabled version of EISCAT realtime data display program.
-> Options: -v
-d dir
-s K|S|T|V|L|2|P|Z
-n dumps_secs
-> Command: start|stop, default is "start"
Examples
webtg stop
webtg -n 60
See also
rtg
windowmanager --
Operations related to Eros windows.
Synopsis
windowmanager file
windowmanager geom ? -leftalign | -verticalalign ?
windowmanager save ? -leftalign | -verticalalign ?
Description
-> Since EROS version 5.7.6, the positions and sizes (the "geometry") of EROS
windows can be adjusted interactively and then saved to a file using the
'save' subcommand, so that when EROS is next time launched, the saved positions
come into use. At the same time, the old window specification file in EROS boot
directory has been mostly taken out of use. It still specifies fonts, though.
-> The positions are saved to a file whos name can be queried with the 'file' subcommand.
Currently, the file contains Tcl code, and is simply sourced at EROS boot-up. But
the file format might change. The files are not meant to be edited by hand.
-> The 'geom' subcommand lists the current geometry of EROS windows.
-> The alignment options can be used to align the currently mapped (non-iconised) EROS
windows with respect to the EROS console window, whether or not the console itself is visible.
The 'left' alignment only aligns the left edges, the 'ver' alignment aligns both left
and right edges. More precisely the 'ver' option aligns the left edge and sets the number of
characters in lines to be the same as in the console window.
-> The EROS start-up command has the option -reset that can be used to force default
window positions, a group of tightly stacked windows in upper right corner, even when
there is a saved position available in a file. There is also a more versatile EROS start-up
option '-win <position>' with <position> one of 'reset', 'north', 'east', 'ne' (north-east,
the default), nne, or nnw. These different <position>s are meant to ease initial positioning
when multiple EROS systems are running on a single desktop, such as when using the EROS simulator.
-> Because the windows are saved to the file using the X11 geometry format, the actual positions
are screen-size dependent. Therefore, the 'save' subcommand actually saves the positions
to a file with a name that encodes the screen size. When EROS starts, it looks only for
a file with the appropriate size, and radar system, specification. If such file is not found,
default positions are used.
writeexperimentfile --
Copy files to the experiment's information directory.
Synopsis
writeexperimentfile <filename list> ?<directory path>?
Description
-> If the <directory path> is not given explicitly, the default name is
formed based on current values of expid, antname and disk. These
variables are normally set by the startdata command. Thus,
writeexperimentfile in default mode should be given only after the
startdata command for the experiment has been given.
-> If <directory path> is given explicitly, the files in <filename
list> are copied into that directory.
-> If the last path component in <Directory path> is "DATE", that
keyword is replaced by the current data in the format yyyymmdd.
-> The command creates the implied directory if that does not exist.
xdir --
Return absolute pathname of the latest experiment directory.
Synopsis
xdir
Description
-> The experiment directory is the directory where the latest
experiment ELAN file resides. The directory path name becomes
known, either explicitly or implicitly, when the runexperiment or
testexperiment command is given.
-> The command is mainly intended to be used in an ELAN file
to make that file more "relocatable". With xdir, one does not
need to hardcode the experiment directory name in the ELAN file,
as most experiment currently do. Most ELAN files define the experiment
directory by hardcodding the value of a variable typically called XDIR.
The simplest way to use xdir is to replace the hardcoded value by
xdir, as in "set XDIR [xdir]".
-> Then it is possible to copy an experiment directory to a different
place for, say, testing, without any modification in the ELAN file.
-> The experiment directory is also shown by the printexperiment command.
Xs2Ys --
Convert sec <--> millisec <--> microsec, with embedded units.
Synopsis
Xs2Ys <time str> <default input unit> <result unit>
Description
-> Convert s|ms|us to s|ms|us, with bossibly the input unit read
directly from the input string.
-> In seconds to milliseconds conversion and seconds to microseconds conversion,
the result is rounded to an integer.
-> In microsec to seconds conversion the result is rounded to microsec accuracy.
-> In millisec to seconds conversion the result is rounded to millisec accuracy.
-> <default input unit> is always required, but is used only if
there is no embedded unit in <time str>.
-> The <result unit> is always required.
Examples
Xs2Ys 6.4 s s ==> 6.4
Xs2Ys 6.4 s us ==> 6400000
Xs2Ys 6.4s us us ==> 6400000
Xs2Ys 6456781us us s ==> 6.456781
[Xx2Ys] 1.2345678s s ms ==> 1235
[Xx2Ys] 1234.6ms s s ==> 1.235
Xs2Ys 6450000 us s ==> error