EROS5 Command Reference

Command List

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