Document version 9-Jan-2004 08:00 UT, Jm.
Update has been completed at ESR.
The purpose of this EROS4 update is to make it possible to control two ESR receivers and the transmitter from a single copy of EROS. Basically, a receiver selector parameter has been added to the following user-level commands. An addition, numerous other routines have been updated to support these changes.
EROS supports the model of the ESR hardware shown in the picture below (a more technical view as a PDF file can be downloaded here). EISCAT now has at ESR four complete analogue receiver chains, attached to two independent digital signal processing systems. EROS considers the system to comprise of two receivers, the ION and the PLA receivers. The ION receiver is for general purpose use, the PLA receiver is configured for plasma-line measurements. The digital part of the ION receiver is identical to the digital receivers at all EISCAT mainland radars.
We need to be able to specify in the receiver-related EROS commands which receiver the command is meant for. For the most part, this is straightforward, we only add a receiver selector parameter to the respective command. For instance, it used to be sufficient to stop the correlator (lag_wrap) program by saying
correlator stop,
but now we need to decide whether we really want to say
correlator ion stop,
correlator pla stop
or
correlator all stop.
We attempt to preserve some degree of backward compatibility (existing ELAN files should still work), and want to allow testing ion-line ESR experiments at other EISCAT sites (EROS should not give an error in Tromso when it sees a command like correlator ion stop). In most cases, both requiresements are realised by implementing both "ion" and "rec" as meaning the ION receiver at ESR, and the (one and only) receiver at the other radar, and quietly ignoring commands containg pla at the other sites.
In this document, we list the modified EROS commands, specifying the use of the switches ion, pla and rec, tra and all.
Note1. In this implementation, options -pla and -ion are mutually exclusive unless explicitly noted otherwise, and the latest is then respected if both are given. Normally, the switch can be placed anywhere after the command name. Thus both recorder -pla stop and recorder stop -pla are accepted. A hyphen in front of ion and pla is optional. Only the first three (non-hyphen) letters are significant in the receiver selector, so plas, plasma and plasmalinereceiver are all valid.
Note2. In EISCAT data dumps, parameter block item d_parbl(41), called antenna ID, has been indicating the antenna. The antenna name has also been part of the data file names, as the postfix @xxx. We now generalize this notion slightly, to be able to differentiate between 32m antenna data taken via the PLA and ION receivers, respectively. Instead of antenna ID, we will speak about the datasource. So far, the EISCAT datasources have been 32m, 42m, uhf, vhf, kir, sod (and, for test purposes, zod). We now introduce a new datasource, datasource 32p (see the command startdata). The datasource 32p refers to 32m antenna data processed through the PLA receiver. The corresponding numeric value in d_parbl(41) is 8. The datasources 32m (=1) and 42m (=2) refer to data produced by the ION receiver. Analysis and display programs might need to take notice.
Note3. This EROS4 update tries to keep existing functionality intact. A minor exception concernes the mount command. So far, it has been possible to request EROS to dump data to whatever directory the user has wanted. We now impose a restriction. The root directory for data dumping can now only be one of predefined directories, as specified in the EROS configuration file eros4/boot/boot_config.tcl. The benefit is that it is easier now for various programs to know where to look for the data. Also, mneumonics of type discN can now be used besides the actual path names in the mount command. And finally, all sites will have at least a disc1 available (this is checked at EROS boot time, EROS will fail to come up if the implied directory is not available and writable).
Note4. This updated brings two new commands to EROS at ESR. The command selectlo can be used to select one of two local oscillators on each of the plasma line signal paths. The command setattenuator can be used to adjust the attenuator on each of the ion line signal paths.
Q. Should we have separate datasources also for the upshifted and the downshifted paths of the PLA receiver?
The recorder command is used to manage the decoder/recorder program decodump. Normally the recorder command is used only implicitly, via the startdata and stopdata commands. Nevertheless, here are some of the command possibilities.
recorder stop
recorder -ion stop
recorder -pla stop
recorder pid
recorder -ion pid
recorder -pla pid
recorder
recorder -ion
recorder -pla
recorder -mount dirname
recorder -ion -mount dirname
recorder -pla -mount dirname
The correlator command is used to manage the program lag_wrap. Normally, the correlator command is used only implicitly, via the startdata and stopdata commands.
correlator name.fil
correlator ion name.fil
correlator pla name.fil
correlator stop
correlator ion stop
correlator ion stop
correlator pid
correlator ion pid
correlator pla pid
The startdata command starts correlator and recorder, and specifies some key parameters to EROS.
startdata ?ion|rec|pla? filfile expid iper_usec ?antenna?
The default is ion at ESR; at other radars, antenna is ignored, and datasource is forced to the unique value of the radar, like "vhf".
For pla, antenna is ignored (even if it would be a nonsense or misleading value) and the datasource is always set to 32p. In dump parameterblock, datasource 32p is assigned number 8.
For ion, antenna can be either 32m or 42m; default is 32m. The datasource is set equal to antenna. In parameterblock, the source numbers are 1 (for 32m) and 2 (for 42m)
E: startdata tau0.fil "kst0 tau0l_fixed_5.00_CP" 6400000 42m
E: startdata ion tau0.fil "kst0 tau0l_fixed_5.00_CP" 6400000 42m
E: startdata pla plasma0.fil "kst0 plasma0_fixed_1.00_SP" 5000000
E: startdata pla myplasma.fil "kst0 myplasma_fixed_1.00_SP" 5000000 42m
Note that Eros does not check that the antenna implied by datasource actually is the data source at any given time. It is the experiment designer's responsibility to ensure that this is the case. The command changedatasource might be of help.
stopdata ?ion|rec|pla|all?
At ESR, the default is ion. At other sites, ion and is all imply rec, and the command "stopdata pla" is quietly ignored.
restartdata ?ion|pla|all?
At ESR, the default is ion. At the other sites, both ion and all imply rec, and the command "stopdata pla" is quietly ignored.
mount ?ion|pla? ?disk?
At ESR, the default is ion. The receiver selector is ignored at the other sites.
This form of the mount command instructs the implied recorder to use disk as the new root directory for data files. The disk can either be an absolute directory path name, which then must be one of predefined directory names, specified to EROS via the Disklist entry in boot_config.tcl file. Or disk can be a symbolic name of the form discN, to refer to the N'th element in the implied receiver's Disklist.
mount ?-ion|-pla?
This form of mount command returns the name of currently mounted disk.
mount ?-ion|-pla? ls
This form of mount command list info of available disks (those defined in Disklist).
printdataaccess ?-ion|-pla?
printdataaccess ?ion|pla?
Default at ESR is -ion. The option is ignored at other sites.
enablerecording ?-ion|-pla|-all?
enablerecording ?ion|pla|all?
Default at ESR is -ion. The option is ignored at other sites.
disablerecording ?-ion|-pla|-all?
disablerecording ?ion|pla|all?
Default at ESR is -ion. The option is ignored at other sites.
stopradar ?-rec|-trans|-all|-pla|-ion?
stopradar ?rec|trans|all|pla|ion?
At all sites, default is -rec. The option -rec stops all available receiver radar controllers, in the order given in the Reclist entry of boot_config.tcl. Thus, at ESR, stopradar -rec stops both ION and PLA radar controllers. The options -pla and -ion are ignored at the other sites.
The option all causes all the available radar controllors to be stopped, including the transmitter radar controller.
E: stopradar rec
E: stopradar
E: stopradar pla
E: stopradar ion
The armradar command serves two purposes. First, it makes a stopped radar controller sensitive to a start trigger from the timing system. Second, it allows changing the running RC's restart address, thus making possible radar controller program change in-flight (at the start of next integration period).
armradar ?-rec|-trans|-pla|-ion|-all? ?-progN?
armradar ?rec|trans|pla|ion|all? ?-progN?
If the R/C is not specified, -rec is assumed. This arms all the receiver radar controllers (to the same start address -progN).
E: armradar
E: armradar rec
E: armradar ion -prog1
E: armradar pla -prog2
E: armradar trans -prog1
Load radar controller program and various control register values, and make prongN-RC_address assignments. It is possible to load both receiver radar controllers in an identical fashion by a single call via the use of the -rec option.
loadradar rec|tra|pla|ion -loopc nloops -file filename
E: loadradar rec -file name.rbin ...
E: loadradar ion -file name.rbin ...
E: load pla -file name.rbin ...
E: load trans -file name.tbin
Schedule the radar's timing system (the TrueTime-systems) to generate start trigger pulse to all of the site's radar controllers.
The startradar command must include enough parameters to allow EROS to compute, to the near future, a suitable time instant that is then fed to the TrueTime time comparison system. (When the actual time becomes greater than or equal to the comparison time, the trigger is sent out).
When the experiment is started initially, so that start time is in the future, computing the RC start time is not an issue. But what should we do when we have stopped after a two- week run of tau0, and want to restart?
We normally want to catch-up with the original integration period cycling. To compute the proper RC start time, EROS needs to know the integration period and the experiment start time. The standard way to specify this info for EROS is to use the startradar command in the ELAN file,
startradar EXPSTART integration_period.
Here EXPSTART is a keyword that tells EROS that it must synchronize the RC start to the experiment start time as given in the last runexperiment command, and the parameter is integration period in fractional seconds (0.1 s fractions are allowed, but not smaller, due to numerical inaccuracy of the underlying tcl language-we cannot risk rounding errors here).
This is what EROS has been doing so far at all sites. But now, at ESR, we have two separate radar controllers and two independent correlator and recorder programs, and thus in principle we could use two different integration times also.
But how would we then synchronize when we were to restart an
experiment? We have only the single startradar trigger available, so how would
we guarantee that the computed new RC start time is an integration period
boundary for two different, possibly relative prime, integration periods?
People who have been crumbling about the peculiar 6.4 s integration period of
tau0 gain a point here.
We would need to resort to starting the PLA and ION radar
controllers at different times. This is possible, by arming the RCs at
different times, but to do this automatically in all cases, we would need to
enforce a connections between the so-far independent armradar and startradar
commands. This appears complicated. Therefore, for the time being, we make the
following
Recommendation: Consider using only a single integration period throughout your experiment file.
EROS does not enforce this rule. If you want, you can let your radar controllers run independently, with different looping, and you can specify whatever integration periods you want in the startdata commands. But when making a restart, the semantics of the command
startradar EXPSTART number
in the ELAN file is such that the number given in the command, and it only, is the "integration period" that EROS actually uses when it skips integrations to find the restart trigger time.
changedatasource ?-ion|-pla? antenna progN delay_sec
The command is intended for ION (which is the default), where antenna can be 42m or 32m. The command does not make much sense in PLA, where we do not allow changing the antenna from 32m. It is possible to use the command for delayed change of RC program in PLA, though.
loadfilter ?-ion|-pla? name.fir channellist
If neither -ion nor -plasma is given, -ion is used.
Note that the ION and PLA digital receivers use different clock rates, and therefore cannot use the same .fir files. The convention has been that file names starting with "w" refer to the 10 MHz system and file names starting with "b" refer to the 15 MHz system.
This convention is now enforced by loadfilter.
loadfrequency ?-ion|-pla? name.nco channellist
If neither -ion nor -plasma is given, -ion is used.
Note that the ION and PLA receivers use different frequency mappings, so they normally would not use the same .nco files.
setfrequency ?-ion|-pla? channellist frequency
If neither -ion nor -plasma is given, -ion is used.
selectlo signalpath
oscillator
The signal path name can be either "upshifted" or "downshifted" (or 1 or 2). The oscillator depends on the signalpath. For the upshifted path, oscillator can be 438|H|8 or 434|L|4, for the downshifted path, oscillator can be 428|H|(-)4 or 424|L|(-)8.
E: selectlo up 438
E: selectlo up H
E: selectlo up 8
E: selectlo down 426
E: selectlo down H
E: selectlo down -4
setattenuator signalpath attenuation
The command sets the attenuator in an ionline signal path at ESR (the plasma line paths do at present not have an adjustable attenuator). The signalpath name can be either 32m or 42m. The attenuation value must be an integer between 0 and 63.
E: setattenuator 42m 16