Heating Command Reference
-
This command reference was automatically extracted from EROS source files as of 04-Aug-2017.
-
Commands may be abbreviated from the end when given
from EROS command line. In elan files, the full
command name must be used.
-
In command synopsis, ?XXX?
means an optional parameter and XXX... means
XXX followed by zero or more repetion of XXX.
-
In commands, the DDS boards are refered to by b1,..., b6, and m.
-
DDS modules, two on each board, are refered to by t1,..., t12,
and m1 and m2.
adj_off
autotuning OFF on selected tx modules.
Synopsis
adj_off <TxList>
auto_tune_off <TxList>
Description
Equivalent to pushing the black 'STOP' button in manual mode.
Effectively also the same as the stop_c1c2 command.
This disables the automatic tuning and matching feedback circuits
within the transmitter which set the variable capacitors c1 and c2
to their optimum values to give maximum power out for the given frequency.
Unlike the adj_on command which also turns on the driver, it does NOT
turn the driver off.
To turn the driver off use the pushbutton df command
adj_on
autotuning ON on selected tx modules.
Synopsis
adj_on <TxList>
[auto_tune_on] <TxList>
Description
Equivalent to pushing the orange 'ADJUSTMENT' button in manual mode.
This enables the automatic tuning and matching feedback circuits
within the transmitter which set the variable capacitors c1 and c2
to their optimum values to give maximum power out for the given frequency.
This also turns on the driver if it is not already on.
Use adj_off or stop_c1c2 to turn adjustment off.
ampgen
Create amplitude modulation files for the Heating exciter.
Synopsis
ampgen ?<OPTIONS>? -f <freq>|-P <period> -s <nsamples>
Description
-> The Heating exciter can produce amplitude modulated output of the
form
y(t) = A(t) * cos(2*pi*f0*t + Phi0)
The carrier frequency f0 and carrier phase offset Phi0 are
controlled separately using, e.g. the sethfrequency and sethphase
commmands, while the purpose of the ampgen command is to define
one period of the periodic modulation factor A(t). The waveform
A(t) is defined by specifying a set of amplitude values A_n = A(n*dt),
using one of several possible parametrized algorithms. The overall
shape of A(t) is selected using the OPTION -m, and its details
are specified using other ampgen parameters and OPTIONS. ampgen
writes the amplitude values to a file from which they can be
uploaded to the exciter amplitude RAMs using the loaddds command.
-> The ampgen command is a wrapper for the Unix-level command
eros5/heating/bin/amp_gen.py. The command creates two files
1) A waveform file that contains the waveform samples A_n of one period of
the amplitude modulation. This file is either of type .sh
or type .amp, depending on whether the OPTION -A is used
(==> .amp) or not (==> .sh). See the documentation of loaddds.
2) A simple example transmitter radar control .tlan file that contains
the signals STMC and UPD needed to kick the A_n values
from the exciter RAMs to active use.
-> In the minimum, two parameters must be explicitly provided to
specify the waveform A(t). First, either
-f Freq: This specifies the frequency of A(t) in Hz,
or, equivalently,
-P Period: This specifies the period of A(t) in seconds.
In addition,
-s Nsamples: This specifies the required number of the A_n samples.
If only these two are explicitly given, then a default sinusoidal
amplitude modulation is generated.
-> Note that, by itself, an .amp (or .sh) file does not contain any
timing information. The Period/Freq in physical units is ultimately
determined by the .tlan file.
OPTIONS
-m sin|ramp|pulse: This defines the overall shape of A(t).
SIN is for sinusoid, RAMP for a linearly increasing
ramp, and PULSE for a two-level pulse so that the first half of the
period has the higher value level. Default shape is SIN.
-d Depth | -p PeakToPeak: Either one can be used to define the modulation
strength. DEPTH is a decimal number between 0 and 100 inclusive,
PEAKTOPEAK is a decimal number between 0 and 1 inclusive. Default
is -d 100 or equivalently -p 1, in which case SIN varies between maximal
amplitude (MaxAmp) and zero, starting from 0.5*MaxAmp;
RAMP increases from zero to MaxAmp; and PULSE has MaxAmp
during the first half of the period, and zero during the second half.
Note that we define the modulation DEPTH to be the ratio (in %)
of half of the peak-to-peak variation to the mean value, and
generate a maximally strong signal. For example,
with -d 50, the SIN varies between MaxAmp and MaxAmp/3, around
the mean level at 2*MaxAmp/3.
-S SCALE: This scales down the "MaxAmp", MaxAmp --> SCALE*MaxAmp. SCALE
must be a decimal number between 0 and 1.
-v: This flag set verbose mode.
-A: This flag results in the generation of "plain-amplitude" (.amp)
output file. If the flag is not used, a "loader-script" file (.sh)
is generated. See loaddds for a little more info about these files.
-o NAME: This controls output file names. Without the option, the
output files are out.tlan and either out.amp or out.sh, depending
on whether -A is used or not. The reserved NAME "auto" results in
file names that are based on the modulation parameters.
-i IPER: If this options is used, ampgen also outputs the radar
controller loopcounter and syncerrorcounter values needed to
achieve integration period IPER (in seconds).
auto_tune
See adj_on
autotuning
Set auto-tuning on or off on specified Heating transmitter units.
Synopsis
autotuning on|off ? TXLIST... ?
Description
autotuning on is equivalent to pushing the orange 'ADJUSTMENT' button
and autotuning off is equivalent to pushing the black 'STOP' button in manual mode.
This enables/disables the automatic tuning and matching feedback circuits
within the transmitter which set the variable capacitors c1 and c2
to their optimum values to give maximum power out for the given frequency.
autotuning on also turns on the driver if it is not already on. One can
also use[adj_on] to do the same.
Use adj_off, autotuning off or stop_c1c2 to turn adjustment off.
-> Turn autotuning on or off on specified TX units.
-> TXlist can be given in various form, such as
t1
"t1 t2 t3"
t1,2,3
all ==> t1,2,3,4,5,6,7,8,9,10,11,12
t* ==> t1,2,3,4,5,6,7,8,9,10,11,12
-> The order of the command arguments is not significant.
-> Default TXLIST is "all".
Examples
autotuning t1 on
autotuning on t12 t11
autotuning off
autotuning all off
autotuning off t1,2,3,4 t11,12
See also
adj_on adj_off setcapacitor
beam
Heater beam-handling command.
Synopsis
beam ~def <Name> ?<Tx list>? ?-f <Val>? ?-p <Val>? ?-z <Val>? ?X|O|NS|EW? ?A<n>? ?B<n>?
beam ~get ?-started? <Name> ?-beam? ?-dds? ?-def?
beam ~info <Name> ?-beam? ?-dds? ?-def?
beam ~load <Name> <Filename>.bdef
beam ~ls ?-started? ?-defined? ?<Pattern>?
beam ~off|~stop <Name>|all ?<Name>...?
beam ~on|~start <Name> ?<Name>...? ?-nosetref?
beam ~save ?-started? <Name> <Filename>.bdef
beam ~set <Name> ?-p <Val>? ?-f <Val>? ?-z <Val>? ?X|O|NS|EW? ?A<n>? ?B<n>?
beam ~undef <Name>|all ?<Name>...?
Description
ONLINE HELP
All the beam subcommands accept the command argument -h or ? to display subcommand-
specific help. E.g.
beam ~def ?
gives online help for the beam defining subcommand ~def.
WHAT IS A BEAM
Usage of transmitter/Exiter units can be orginized into "beams". In this context,
a beam means both a physical beam of radiation produced by a set of transmitters,
as well as the hardware and software settings required to create the radiation. Thus,
a beam consists of a set of transmitter and associated exicer modules, with specific
settings. There could be any number of beams, and in the present implementation, it is
entirely the user's responsibility to ensure that the beams do not overlap,
that is, that any given transmitter/exciter unit is used by at most a single
active beam at any given time. Also, it is the user's responsibility to ensure that
once a beam is turned on, it is not modified e.g. by fiddling interactively with the
associated exciter modules using lower level commands like sethamplitude.
TWO KINDS OF BEAMS
At any moment, there can be two kinds of beam descriptors known to EROS: "started"
beams and "merely defined" beams. A beam with a given <Name> can belong to either or
both of these sets. The started beams are those that have been uploaded into exciter
using beam ~on, alias beam ~start. The merely defined beams instead exist only
internally in EROS.
-> Why the two kinds?
It can be confusing to have two kinds of beam definitions around. It would be
possible to implement things so that when a beam is started, its definition
would be cleared from the set of merely defined beams, and when a beam is stopped, its
definition would be moved from the started beams to the merely defined beams. Then
a given <Name> would only exist in one or the other of the two sets at any given time,
and thus only a single set actually would be needed. The main justification for the
present arrangement is that it allows EROS always maintain an accurate representation of
all active beams, even when a beam is being modified by a user. A beam must be modified
in EROS memory _before_ it can be physically uploaded to exciter, and during that time
(after modification and before upload, possibly a long time especially if multiple
beams are involved) at least, the beam definition in memory and the actual beam
settings in hardware would _necessarily_ be different, which is bad.
CREATING BEAM DEFINITION
Beams must always first be defined in EROS using beam ~def, beam ~set or beam ~load.
Any of these commands adds the new beam descriptor into the set of merely defined beams.
The properties of the merely defined beams can be queried using beam ~info.
DELETING BEAM DEFITION
Beams can be removed from the set of merely defined beams using beam ~undef. After an
~undef, beam ~info no more knows about the beam (but printbeam may know about
a similarly named beam, if that has been started earlier).
TURNING BEAM ON
Any of the beams in the set of defined beams can be activated by uploading its
definition to the exciter hardware using
beam ~on ?-nosetref? <Name> ?<Name>...?
The beam ~on command does three things
*) It makes a copy of the beam definition and places it into the set of started beams.
*) It uploads the definitions (freqs, amps and phases) to the exciter hardware
*) It sets the appropriate reference oscillator (either m1 or m2, or both) to the beam's
frequency. If this is not desired, the flag -nosetref must be used.
The properties of the started beams can be queried using the command printbeam or with
beam ~get -started.
TURNING BEAM OFF
Beams can be turned off using the command
beam ~off <Name> ?<Name>...?
This command does two things. It sets the amplitudes of the affected exciter units to zero,
and it removes the beam's definition from the set of started beams. After the beam
has been stopped, printbeam no more knows about it. It is possible to turn off
all beams using
beam ~off all
BEAM-FORMING PARAMETERS
A beam definition consists of a set of exciter settings affecting the dds units belonging
the the beam. The beam definition also specifies transmitter array and band. Altogether,
the following seven parameters must be assigned.
* Frequency -f <Val><Unit> (e.g. 5.01MHz)
* Power -p <Scale 0...1> | -p <Val>kW
* Zenigh angle -z <Angle in degrees>
* Polarization mode X | O | NS | EW
* Antenna array A1 | A2 | A3
* Transmission band B1 | B2 | B3
* List of transmitters e.g. t1,2,3,4,5,6 | t1 t2 t3 t4 t5 t6 | all
In addition, for bookkeeping and reference, each beam must have a <Name>.
BEAM DEF, BEAM SET and BEAM LOAD
The beamforming parameters can be defined either using
beam ~def <Name> ...
or
beam ~set <Name> ...
The difference is that beam ~def (re-)sets all seven beam-forming
parameters, using system-wide defaults for those parametgers that are not
explicitly specified, while beam ~set only modifies those parameters that
are explicitly specified in the command. Thus, if the beam of <Name> beam6 has
not yet been defined in current session of EROS, both the command
beam ~def beam6
and
beam ~set beam6
create the beam with default values for all parameters. But if the beam beam6
already is defined in EROS, the command
beam ~def beam6
resets all the beam parameters to default values, while the command
beam ~set beam6
does nothing. Use the command
beam ~info beam6 -def
to display the beam design parameters of beam beam6.
-> A beam's definition can also be read to EROS from a beamdef (.bdef) file,
using
beam ~load <Name> <Filename>.bdef
This creates a new beam of name <Name>, or overwrites an existing merely
defined beam with the given <Name>.
BEAM SAVE
A beam definition can be saved to a file by the commands
beam ~save <Name> <Filename>.bdef
and
beam ~save -started <Name> <Filename>.bdef.
A saved beam can be recalled back to EROS memory using beam ~load.
BEAM ON alias BEAM START
The commands beam ~def and beam ~set only create a beamdef data
structure in EROS (an in memory only at the preset, so the definition is lost
if EROS crashes), but do not touch the exciter hardware. To actually upload
the beam definition to the exciter hardware, and thus to get the beam into
the air once the transmitter is powered up, the command
beam ~on <Name>
which is aliased as
beam ~start <Name>
must be used. The command sets up the exciter by loading the appropriate
frequency, amplitude and phase values to the exciter DDS units. At the moment, the
beam's array and band must be set separately by the operator.
-> Multiple beams can be started in a single command by specifying
several beam names in the beam ~on as
beam ~on <Name1> <Name2> ...
EROS assumes that multiple beams are transmitted by separate antenna
subarrays so that any given DDS unit is used only by at most one of the
concurrent beams. Presently, it is the user's responsibility to ensure that
this is the case. Under this premise, because the beams use different DDS
units, the beams can be started either with a single beam ~on command as
above, or by using multiple commands
beam ~on <Name1>
beam ~on <Name2>
and the resulting exciter state should be the same in both cases.
BEAM LS
The command
beam ~ls <Pattern>
lists the names of beams whose names match the <Pattern>. The search goes
over both the set of merely defined beams and the started beams. The result
give the names separately for the started beams and the merely defined beams.
If no <Pattern> is given, all beams names are listed, both for started and
for merely defined beams. The screen printout looks something like
-on: beam1 -def: {beam1 beam2}
which indicates that there are two merely defined beams, beam1 and beam2,
and one active beam, beam1.
-> It is possible to request lists of the merely defined and the started beams
separately, as Tcl lists (which can then be used as input for further commands).
This is done via the options -def and -started (or -on), respectively, as
beam ~ls -defined ?<Pattern>?
or
beam ~ls -started ?<Pattern>?
BEAM INFO
The command
beam ~info <Name> ?<FLAGS>?
prints to screen various pieces of info about the merely defined beam with name <Name>.
To print out corresponding info about an active beam with name <Name>, use
printbeam <Name> ?<FLAGS>?
-> The amount of info reported by beam ~info is controlled by the flags
-beam, -dds, -def, -v. The actual beam going out of the phased array antenna
depends, in addition to the exciter settings, also about the phase path
lengths from the exciter through the transmitter units to the common feed
point of the antenna array.The signal path from a DDS module to the antenna element
(or rather the common feed point of the element groups) is referred to as
the transmission pathway. There are total of 2x12 possible transmission
pathways in the heating system, 12 for each of the two arrays A1 and A2. It
makes sense to speak about the "ideal" or "design" array element phases on
one hand and the required actual phases in the exciter on the other hand.
The design information is referred to here as the BeamTable, and the required
actual exciter settings as the DDSTable. In addition, there is a third set of
related information, namely, the seven "physical" beam design parameters like
frequency, zenith angle, polarization and so on. This we refer to as the DesignTable.
-> Beam info FLAGS
-beam: With is option, beam ~info shows the BeamTable. That is,it
prints out the exciter and transmission parameters for the beam as
if all the phase paths from the exciter to the array elements were
of equal length. The printout contains 12 lines, one for each
DDS|TX unit. For the transmission pathway from DDS 6 to the
corresponding array element of antenna A2, the BeamTable line could
look like this
==> T6 0.100 4040.000 90.0 A2 B2
-v: If also the verbose flag -v is also used, two additional
columns are appended to the BeamTable, giving the phase path
length (in units of wavelength) corresponding to the phase offset,
and the equivalent time-steering delay in nanoseconds.
-dds: With this option, beam ~info shows the DDSTable. That is, it
prints out the beam parameters as they actually need to be set in
the exciter to implement the beam. For any beam, _all_ 12
simultaneously available transmission pathways out of the exciter are
listed, but a "-->" at the beginning of a row in the table indicates
that the DDS unit will be used for the referred beam (some other
beams may be using the other DDS units).
A typical row in the 5-column wide DDSTable could looks like this
--> t6 0.100 4040.000 348.8
These five columns are
* DDS unit in-use indicator
* DDS unit name (t1 ... t12)
* DDS unit's amplitude on the scale from 0 to 1
* DDS unit's frequency in kHz
* DDS unit's phase offset in degrees.
-v: If also the verbose flag -v is used, five additional columns
are printed in the DDSTable to indicate how the phase offsets shown
in the phase-offset column were constructed. For instance, for the
DDS unit t6 above, the additional columns could be
1.00 74.21 0.2500 4.7188 4.9688.
These additional verbose-mode DDSTable columns are
* DDS module-specific power calibration factor.
* Beam's wavelength in meters.
* Required total phase-steering phase offset,
at an array element feed-point, in terms of wavelength.
* Equivalent phase path of cables, in terms of wavelength.
* The required equivalent phase path that the DDS must generate.
-def: Print the beam's DesignTable. This is a simple two-line printout
in (hopefully) self-documenting keyword value ... format.
BEAM GET
The beam ~get command returns basically the same info as beam ~info, but
in numeric form, as a Tcl dictionary. For example,
beam ~get beam1 -def
returns dictionary of the definition of beam1. The dictionary fields are
* enc 06f10236 encoded freq
* za 0 zenith angle
* pow 0.12 power on the scale 0...1
* mode X polarization mode
* tx {t1 t2 t3} transmitters used for the beam
* arr A1 array
* band B3 band
The command
beam ~get beam1 -beam
returns a nested dictionary with the fields t1, t2, ... t12. Each of the
fields tn is itself a dictionary, with the fields
* act 1 flag, set when this "tn" is used for the beam
* freq 5422.999... frequency, kHz
* enc 06f10236 frequency, encoded HW value
* pow 0.12 power 0 ... 1
* arr A1
* bnd B3
* pth 0.25 required phase offset in units of wavelength
The command
beam get ~beam1 -dds
returns a nested dictionary with the fields dds1 dds2 ... dds12, where each of the
ddsK is a dictionary with the fields
* act 1
* frq 5433.999...
* enc 06f10236
* amp 0.12
* pha 349.06...
* cal 1.00
* pth 0.25 required phase path at array element, in units of wavelength
* ppa 7.7196... total phase path in cables, in units of wavelength
* dpp 7.9696... path that DDS much "generate", in units of wavelength.
The command can also retrieve similar info about the currently started beams, as e.g.
beam ~get -started beam1 -def
changehamplitude
Change output level on one or more Heating exciter DDS Units.
Synopsis
changehamplitude ?OPTIONS? ?<ddslist>? <amplitude change>
changehamplitude ?OPTIONS? ?<ddslist>? <calibrated power change>dB
changehamplitude ?OPTIONS? ?<ddslist>? <calibrated power change>kW
changehamplitude ?OPTIONS? <dds> <change> ?<dds> <change>...?
Description
The amplitude (the amplitude scaling word, ASW) of the specified DDS units is changed.
-> <dds> and <ddslist> as in sethamplitude.
-> <amplitude change>
is the required dA either of the normalized amplitude 0...1
or the HW word 0x0...0x3FFF. The latter interpretation is used if
<amplitude change> is given in hex like e.g. -0xf, the former, if a decimal notation
like 0.1 is used.
-> <power change>dB
is the required power change in dB. Any value can be used but the final value is
forced to the range specified via the calibration curves (see powercal).
Has now effect on m1 and m2.
-> <power change>kW
changes the power by the given amount of kW. Any value can be given, but the
final ASW is forced to a range given via the calibration curves.
Has now effect on m1 and m2.
-> The current amplitude is taken to be the value currently
maintained by EROS (that is, the value is __not__ actually read
form the HW). Use printdds to display the current value.
-> It is possible to specify different change for different DDS units, by
__explicitly__ specifying as many change values as there are implied
DDS units. Thus
changehamplitude t1 10kW t2 20kW t3 -30kW
and
changehamplitude t1,2,3 10kW 20kW -30kW
are allowed, but
changehamplitude t1 10kW t1,2 20kW
is not.
OPTIONS
-> If the flag -check is used, the current and new value are
shown, but now actual change is performed.
-> If the flag -nowait is used, the command does not check whether
the DDS is really free to use and accessible. Normally, this flag
should not be used. See sethamplitude.
Examples
changehamplitude t1 -20dB # Change the calibrated output power of t1 by -20 dB.
changehamplitude 0.1 # Add 0.1 to all amplitudes (truncates to 0...1 if necessary).
changehamplitude +10dB # Changes t1...t12 calibrated power by 10 dB.
changehamplitude t1 10kW t2 -5kW
changehamplitude m* -3dB # Does nothing (and now warning is given).
See also
sethamplitude printdds powercal
changehphase
Change phase offset of one or more Heating exciter DDS unit.
Synopsis
changehphase ?-verbose? ?-nowait? ?-check? ?-raw? ?<ddslist>? <Phase>
changehphase ?-verbose? ?-nowait? ?-check? ?-raw? <dds> <Phase> ?<dds> <Phase>...?
Description
-> In the first form of the command, the phase offset word on all the
specified DDS units are changed by the given <Phase>. In the second
form of the command, it is possible to specify several DDS units and
their changes separately.
-> The new phase is always forced to the legal range 0...360-eps.
-> The current phase is taken to be the value last set by
EROS, as maintained by EROS; the value is __not__ read from
the hardware and is undefined after EROS boot.
Use printdds to display the current values.
-> <dds> and <ddslist> are as in sethamplitude.
OPTIONS
-> If the flag -raw is used, the <Phase> must be an integer, and is assumed
to represent a change to the internal hardware bit-value.
-> If the flag -check is used, the current and new value are
shown, but the new value is not written to HW.
-> If the flag -verbose is used, the current and new values are printed
at return.
-> If the flag -nowait is used, the command does not check whether
the exciter is really free to use (not being used by R/C). By default,
the command does wait. See sethamplitude for more info about this matter.
Examples
changehphase t1 -15
changehphase t1 -15.1 t2 +10 t3 20.5
changehphase t1 -v t1,2,3 10
See also
sethphase changehamplitude printdds
computer_control_off
Disables exclusive computer control of some console buttons for all transmitters
Synopsis
computer_control_off
pc_control_off
Description
Note that this does NOT switch control to 'manual' (the lit grey button).
It just enables one to use the manual button. Computer control is still
possible as long as the orange 'PET' button is lit. Once the 'MANUAL' button
is lit then computer reading and control no longer works.
See also
computer_control_on aka pc_control_on
computer_control_on
Enable computer control of some console buttons for all transmitters
Synopsis
computer_control_on
pc_control_on
Description
It will light up the orange button labelled 'PET',
enable computer control of some buttons and enable reading of
digitized parameters from the transmitters. Manual control is disabled
until the computer_control_off aka pc_control_off command is given.
dds
Initialize and/or configure the Heating exciter from a file.
Synopsis
dds sync
dds init ?<BoardList>?
dds initboard ?<BoardList>?
dds save <SaveFile>
dds <Task> ?<Task>...? ?-using <ConfFile>? ?<BoardList>?
Description
-> The dds command is used to load center frequencies, amplitude scaling
factors and phase offsets, based on information in a configuration (.conf)
file, via the subcommands pha, amp and freq; or to do full or partial
initialization of the exciter using subcommands init or initboard. The sync
command is used to synchronize the DDS outputs. Moreover, it is possible to
save current configuration to a .conf file using the subcommand save. The
subcommands reset and setall are just shorthands for certain combination of
the elementary subcommands.
-> sync: Synchronize all DDS units. Should normally be given after an
interactive frequency change, because when the freq is changed one DDS
unit at a time (even while using a single sethfrequency, the actual
setting is one DDS at a time, sequentially), the earliest changed DDS
units run the new frequencies the longest times, and so the outputs will
get out of phase. Note, incidentally, that if the frequencies are changed
under R/C control the change should be simultaneous, and so the
frequencies _should_ stay in phase. This seems not to hold true, though.
-> init: Initialize the MPV interface, the given exciter motherboards, and both
DDS units on each of those boards.
-> initboard: Initialize the given DDS motherboards, and both DDS units on each
of those boards.
-> save: Save currently set amp, freq and phase to <SaveFile> in the conf file
format. Can be restored using "dds setall".
-> <Task> is one of phase | amp | freq: The purpose is to read the specified
items from a configuration file and upload them to the boards in BLIST. The
default configuration file is defined in the EROS [eGet] configuration
database (eros/boot/boot_config.tcl) as the item hotconfig, e.g.
/kst/etc/hotconfig.conf. The default conf is used if the option "-using
<ConfFile>" is not given in the dds <Task> commands.
-> <BoardList> = <BoardSpec> ?<BoardSpec> ...?
where
<BoardSpec> = b<n>?,<n>...? , n=1...6
or
<BoardSpec> = b* , this is equivalent to b1,2,3,4,5,6
or
<BoardSpec> = "m"
or
<BoardSpec> = "all", this is equivalent to "m b*".
If <BoardList> is not specified, "all" is assumed.
-> The DDS units t1...t12, on boards b1-b6, provide the RF driver signals to the
transmitters T1-T12, DDS units m1 and m2, on the "master" board m, are for
system synchronization. The master m1 is used to synchronize all the DDS units
so that they all start at the currently set phase offsets simultaneously. The
master m1 provides a common frequency reference to transmitter units T1-T6, m2
provides a common frequency reference to transmitter units T7-T12. These
reference signals are used when reading various phase parameters back from the
transmitters.
-> In addition of the basic dds subcommands init, initboard, sync, phase, amp
and freq, the following combined subcommands can be used (note that they make
use of a config file, either the default one or an explicitly specified file).
* reset, which is equivalen to "init amp freq sync pha" * setall, which is
equivalent to "amp freq sync pha."
-> In this version, if one wants to configure only part that the exciter from the
config file, that "part" is determined as a set of exciter boards, not
individual DDS units.
Examples
dds init m b1,2,3
dds init m b1 b2 b3
==> Initialize the MPV interface board and the
DDS boards master, board1, board2 and board3.
dds freq sync
==> Read frequencies from file [eGet] hotconfig and upload
them to the boards, then synchronize the boards.
dds amp pha -using myconf.conf b*
==> Read amplitudes and phase offsets from myconf.conf
and upload them to the DDS modules on DDS boards b1-b6.
See also
sethphase sethfrequency sethamplitude
decode
Convert exciter HW phase|amplitude|frequency integer value to a double.
Synopsis
decode <What> <Value> ?<Value>...?
decode <What> <ValueList>
Description
This is a utitily to convert DDS HW hex values to "physical" values.
-> <What> = pha|amp|freq
-> <Value> is the HW value, as a hex string, with or without the 0x prefix.
<ValueList> is a list of Values.
-> If there are no errors, a list of doubles is returned.
Examples
decode a 1333
decode p 1000 2000
decode freq 0x052bd3c3
deselectddsboard
Deselect all Heating exciter boards.
Synopsis
deselectddsboard
Description
When a exciter board is in the "selected" state, an interactive
command can change phase, amplitude or frequency on the DDS units
in the board, and conversely, the data flow from the RAM is
inhibited. The command returns all the boards to the not-selected
state.
Examples
deselectddsboard
See also
selectddsboard
fast_capacitor_movement
Sets the capacitor speed to fast for both C1 and C2 for all transmitters.
Synopsis
fast_capacitor_movement
Description
Sets the speed of the tuning (C1) and matching (C2) variable vacuum capacitors
to fast for all transmitters. This should be the default speed.
Equivalent to pushing the grey common button 'FAST' in manual mode.
see also slow_capacitor_movement
freqinfo
This commands just returns info about heating frequencies.
gethamplitude
Return current DDS amplitude value.
Synopsis
gethamplitude ?<format> <format> ...>? ?<ddslist>?
Description
Fetch current value of the specified DDS units from EROS internal bookkeeping.
The returned values are formatted according to <format> specs.
-> <ddslist> as in sethamplitude
-> <format> = -x | -f | <floatingpointformat>
<floatingpointformat> is any valid formating spec for a float, such as "%1.4f".
-x returns the HW value in hex string e.g. 0x1234
-f returns the decoded value in tcl default high precision floating format,
The default format is "%f", floating point with about six decimal places.
Examples
gethamplitude ;# Return all 14 decoded amplitudes in the %f format.
gethamplitude t1 t2 ;# Return decoded amplitude for t1 and t2 using the %f format.
gethamplitude -x t1 ;# Return HW amplitude for t1 in hex.
See also
printdds sethamplitude
hall
Control some Heating transmitter hall auxiliary systems
Syntax
hall <operation>
Description
<operation>:
wateron wn waterpump on
wateroff wf waterpump off
autoon an automatic temperature regulation on
autooff af automatic temperature regulation off
vent100 vn ventilation full speed
vent50 vh ventilation half speed
ventoff vf ventilation off
heaton hn heater element on
heatoff hf heater element off
See also
readhall
heating
List heating-specific EROS commands.
Synopsis
heating
help heating
hfcommand
Send a command file to Heating PET computer.
Synopsis
hfcommand FileName
Description
The EROS interface to the Heating TX is via simple text
files. Normally, EROS commands such as setcapacitor or
autotuning pr [printhf] prepare such file based on the
command parameters and then made the file available to the
'Pet' program that actually accesses the transmitters. It is
also possible to create such a command file by an external
editor, and use this command to deliver that file to the
'Pet' program.
Example
Prepare the file mycapset.txt with the following four lines
1
2
1,3
2,4.74,2,4.04
Delivering this file to the 'Pet' by
hfcommand mycapset.txt
is equivalent to using the command
setcapacitor tx1 b2,4.74 tx3 b2,4.04
hfox
Communicate with the TX control computer ("hfox")
Synopsis
hfox Subcommand ?Arg...?
hfox reconnect
Description
...(missing)...
hxconsole
Communicate with the Heating console computer (h51)
Synopsis
hxconsole ?-async? <Command> ?<Arg>...?
Description
Send (via EXPRUN) arbitrary commands to the wish running in the console
computer. With the flag -async, use aSend instead of Send for sending
(no reply is returned then).
loadcaps
Read caps from file and set the caps in HW.
Synopsis
loadcaps -?exact? ?<txlist>? ?<capsfile>?
Description
-> <txlist> is of the from "t<n> t<n> ..." or "all". Default is "all".
-> <capsfile> must be of the format described in savecaps, and have the extension .caps.
If <capsfile> is missing, the file name defined in boot_config.tcl is tried.
-> If a <txlist> is given explicitly, it is an error if valid values are not specified
in the file for all of the requested tx units. If no <txlist> is given
explicitly, requests to set the non-specified caps are silently ignored.
-> If all implied tx units have both of their cap specs valid, the setting is done simultaneously
using set_c1c2, else the setting is done using set_c1 and set_c2.
-> If -exact is not set explicitly, at most those caps are set which belong to tx units
which are powered-up, according to txmodule_status.
Examples
loadcaps ;# Set those caps that have valid spec in the file.
loadcaps all ;# This requires that all 12+12 caps have valid spec, else an error.
loadcaps t1 t2 t3 t4 mycaps.caps ;# This requires valid spec for both caps of t1,2,3,4.
See also
savecaps
loaddds
Load amplitude, frequency, and phase data from file to the Heating exciter RAM.
Synopsis
loaddds <file>.sh ?<boardlist>?
loaddds ?<ddslist>? <paffile> ?OPTIONS?
Description
-> Each of the 14 DDS units of the Heating exciter is connected to its own
16 kByte RAM module, located on the exciter motherboards. The RAMs
can hold various types of words. These words have the structure
(*) word = <destination><value>
where the <destination> specifies either the Frequency Tuning Word (FTW)
register, the Phase Offset Word (POW) register, or the Amplitude Scaling
Factor (ASF) register onboard the AD9953 DDS chip, and the <value>
specifies the value to be loaded into the register.
In addition of these three word types, there is also a NOP ("no
operation") word of length of two bytes. Or rather, there is no proper
NOP in the AD9953 instruction set, but Andrew Senior has been able to find an
instruction that, with the present exciter initialization and use, does not
have any effect to the DDS output.
The <destination> takes up one byte of RAM, the <value> takes two bytes
for amplitude and phase, four bytes for frequency, and one byte (with
value 0) for the NOP. The NOP cannot be specified explicitly in the <paffile>
and is for EROS internal use, for padding, only.
loaddds checks that the 16 kB RAM size limit is respected. For
example, if all three values P,A,F are specified in any block, the maximum
number of BLOCKs (see below) in the <paffile> is 1489 (2^14/11).
-> The contents of the RAM are are taken into active use, that is, transferred
into the DDS registers via input buffers (each DDS register has conceptually
its own buffer) located on the DDS chip. The transfer is done under
transmitter R/C control via a two-stage pipeline operation. Two R/C commands
affect the pipeline, the UPD ("update") and the STMC ("start modulation counter")
commands. An UPD commands causes two things to happen, in the order given.
(1) The current contents of the input buffers are transferred to the
DDS registers and taken "immediately", and simultaneously, into
use. This is done so that phase-continuity of the output waveform
is maintained.
(2) After the transfer (1), an asynchronous transfer from the RAM to
the input buffers is launched. The transfer goes over 1-bit wide
serial interface and requires 40ns per bit, plus about 100ns
overhead. The transfer happens autonomously, under the control of the
exciter board logic circuitry. The number of bits to be transferred is
controlled by a single 7-bit counter per DDS. This counter is
initialized by loaddds. Only integer multiples of 8-bits make
sense, and the number of 8-bits groups (that is, bytes), is set to
the value of the BLOCKLEN parameter present (explicitly or
implicitly) in the <paffile>, as described below.
In addition of the UPD command, a second R/C command, STMC, affects the
RAM-to-DDS pipeline. The STMC command also does two things. It first (re-)sets
the RAM address pointer to the first world to be transfered, and then performs
the above step (2) to start a transfer. But it does __not__ kick the currently
latched values from the input buffers to the DDS.
-> The above structure of the data transfer pipeline ensures that several RAM
words can be packed together into what are called BLOCKs in this document.
Each BLOCK in a <paffile> must contain same number of bytes. This number
is called the BLOCKLEN. A BLOCK is transferred from RAM into the DDS input
buffers asynchronously and rather slowly, but is then taken into use
synchronously and at a precise moment of time via the UPD R/C command (the UPD
command generates what is called the IOUPDAT signal in the AD9953 documentation).
In this way, all three waveform parameters of the DDS output can be changed
synchronously by an R/C command.
-> There exists a small complication due to the pipeline structure of the data
transfer, depending on how how the .tlan file is written.
(A) If the .tlan file is written by having as the first pipeline instruction
simultaneous STMC and UPD, coded as
STMC,UPD
UPD
...
then the following consideration apply:
If one wants the BLOCKs
B1, B2, B3, .. B<N>
as specified in the <paffile> to be kicked into use by <N> successive UPD
tarlan commands, one needs to actually fill the DDS RAM in the
rotated-up-by-one order
B2, B3, ... B<N>, B1.
For .paf files with version < 3, this rotation is enforced by loaddds
and normally users need not care about it explicitly. For .paf files with
version >= 3, the default behaviour is tailored to case (B) below, in which
the first command in the .tlan is a lone STMC, which does __not__ generate
an IOUPDAT but still launches a new data transfer from RAM to DDS. Thus,
with version >= 3 files, if rotation is wanted, the flag "-r" must be
explicitly used.
(B) If the .tlan file is written by having a lone STMC in the beginning,
STMC
UPD
...
then the end result will be such that, essentially, the initial STMC just
initialises the pipeline from the top of the RAM, and only the first UPD
kicks that value to use. In this case, the RAM shoud normally NOT be rotated.
To get this behaviour of loaddds, use version ID 3.0 in the file. If one
wants the RAM rotated with version 3.0 files, use the flag "-rot" explicitly.
The recommended way for most cases is to use the coding scheme (B).
-> Note that, for debugging purposes, it might be useful to be aware of the
following: EROS implements loaddds by generating temp files, of names such
as /tmp/PAFfile_t1.sh, which contain all the various unix- level commands
needed to get the RAM loaded over the VME bus. These files have comments for
debugging purposes, but instead of BLOCK<n>, the comments use terms LOC(<k>)
to refer to the BLOCKs B<n>. The first location, LOC(1), in the /tmp/... file
tells how B2 is loaded, LOC(2) tells how B3 is loaded, and so on. Finally,
BLOCK B1 is loaded last (to the highest RAM address used), as specified by the
commands under the title LOC(<N>).
WARNING (added 2017-08-03)
-> If one uses the Heating exciter RAM to control amplitude, phase or frequency,
by using the loaddds command to load a .paf file together with its
controlling or stepping R/C program, then it is important not to start and
stop the TX radar controller with some other program between the last
dds reset command and starting the stepping R/C program. Running the TX R/C in
this 'forbidden' interval apparently causes the control of the
ampl/phase/freq to be severely disturbed. Loading the .paf file before or
after running this R/C program makes no difference.
-> This feature is not fully understood but perhaps is related to the 'LPRINT'
signal from the RC which changes at the end of every integration period. If
one really has to run some R/C program in this 'forbidden' time, which should be
easily avoidable, a dds init m b* followed by a dds sync m b* command
should be given after this R/C program is stopped and before the stepping R/C
program is started. Then the steps in the .paf file appear to be executed
correctly.
STRUCTURE OF A PAF FILE
-> A <paffile>, which must have the file name extension .paf, is used to
specify the contents to be loaded into the RAM, BLOCK after BLOCK, using the
following rules and formats.
- Comments must start with either # or %. End-of-line commends are allowed.
- Empty lines are allowed.
- The first non-commend line in the <paffile> must specify file format version
as "PAFFILE_VS 3.0", taken into use 28-Nov-2014.
For old .paf files, the version "PAFFILE_VS 2.0" is still accepted, but can
results in different behaviour with respect to RAM rotation, as was
discussion above. In short,
* For files with version < 3, rotation is done unconditionally.
* For files with version >= 3, rotation is by default NOT done, but
can be requested by using the flag "-r".
- After the version specifier line, and before the lines specifying BLOCK
contents, can optionally come a line specifying the BLOCK length. The
length specifier line must have the format
"BLOCKLEN <L> BYTES",
where <L> is between 2 and 15, inclusive.
-If the BLOCKLEN line is used, all the BLOCKs must
* either be explicitly <L> bytes long
or
* must be of lengths <L> - <n>*2, with <n> an integer,
so that the specifications can be padded by EROS to length <L> by adding
two bytes long NOP instruction to the end of the BLOCKs at load-time.
-If the BLOCKLEN line is not used, loaddds determines the smallest
possible <L> at load-time. It is an error if the implied padding cannot be
done using the two-byte NOP instructions (but there may be other ways of
doing the padding, see the examples below).
- After the (max two) header lines, the BLOCK specifications must follow.
A BLOCK is specified by specifying the words comprising the BLOCK, one
word per line, in the form
<n> <type> <value>
where
* <n> is the BLOCK number, counting from 1, and incrementing by one from BLOCK
to BLOCK.
* <type> is A or AMP for ASF, P or PHA for POW, and F or FRQ for FTW.
* <value> is the value of the parameter.
- The <value> can be specified either as HW integer value expressed as the
C-language hex string which starts with the prefix "0x", like "0x12ab", or
<value> can be a "physical" floating point value. The valid range of the HW
values is from 0x0 to 0x3fff for PHA and AMP, and 0x0 to 0x80000000 for
FRQ. The physical PHA must be in degrees, the AMP must be between 0.0 and
1.0 inclusive, and the frequency must be between 0.0 and 100.0 (MHz). See
sethamplitude, sethphase and sethfrequency for the relation
between physical and machine values. Note, however, that not all the physical
value formats available in those command are supported by loaddds.
-> Example 1. An example of a valid <paffile>, with 11-byte implicit BLOCKLEN, is
%---------------------------------------------------------------
% This is a valid paffile having two blocks.
%---------------------------------------------------------------
PAFPAR_VS 2.0 % This first non-comment line is mandatory
1 A 0.5 % 3 bytes, specify half of maximal amplitude. Machine value 0x2000
1 P 90 % 3 bytes, specify phase in degrees. Machine value 0x1000
1 F 4.04 % 5 bytes. freq in MHz. Machine value is 0x052bd3c3
2 P 0x3000 % 3 bytes. Physical value 270 (or -90) degrees.
2 A 1 % 3 bytes. Machine value 0x3fff
2.F 50 % 5 bytes. Machine value 0x40000000
-> The following example uses an explicit BLOCKLEN, but will result with the error
in loaddds telling that on line 6, padding with 1 byte is not possible.
Example 2a.
PAFPAR_VS 2.0
BLOCKLEN 6 BYTES # An explicit BLOCKLEN specification.
# This file is !!! WRONG !!! and is not accepted by loaddds.
1 A 0x2000 # 3 bytes
1 P 0x1000 # 3 bytes
2 F 4.04 # 5 bytes
The problem is that the BLOCK 2 requires five bytes, and cannot be padded
to the requested length of 6 bytes via a 2-byte NOP. One way to correct the
file is to specify the BLOCKLEN to be 8 bytes, and then repeat e.g. the A
instruction of BLOCK 1, so that the file becomes
-> Example 2b.
PAFPAR_VS 2.0 # This line is mandatory.
# This file is OK.
BLOCKLEN 8 BYTES # This line is optional.
1 A 0x2000 # 3 bytes
1 P 0x1000 # 3 bytes. EROS will add a NOP after this word.
2 F 4.04 # 5 bytes
2 A 0x2000 # 3 bytes, repeats A from BLOCK 1.
Now EROS can pad the first block to the common length of 8 bytes using a NOP.
OPTIONS
The options of loaddds allow certain modifications do be done at load-time to
the parameter value to be loaded into the RAMs, compared to what is specified in
the <paffile>.
-> -scaling <scalefactorlist>. This can be used to adjust the overall output
level of the DDS units in the <ddslist>. The <scalefactorlist> is a tcl list
of amplitude scaling factors. At load time, the <AMP value> to loaded to the
RAM is the value in the <paffile> multiplied by the amplitude scaling
factor. All the <AMP values> on a given DDS unit are multiplied by the same
scaling factor, picked from the <scalefactorlist>. The <scalefactorlist> is
used cyclically by loaddds to find a scaling factor for each DDS unit in
<ddslist>. That is, if the <scalefactorlist> is shorter than the (explicit
or implicit) <ddslist>, the <scalefactorlist> is reused as many times as
necessary to find a scaling factor for each DDS unit in <ddslist>. For
example, if the <ddslist> is {t1 t4 t3 t5} and <scalingfactorlist> is <0.7
and 0.8>, all the AMP values in DDS unit t1 and and t3 are scaled by 0.7,
and all the AMP values on DDS units t4 and t5 are scaled by 0.8. The
amplitude scaling factors must be specified as non-negative floating point
values, irrespective whether the AMP values in the <paffile> are specified
in float or HW integer format. It is an error if the scaled amplitude would
become larger than 1.0.
-> -p | -phaseoffset <phaseoffsetlist>. This option can be used to adjust the
<PHA value>s to be loaded to the RAM by adding an offset, picked from
the <phaseoffsetlist>. The <phaseoffsetlist> is a Tcl list of phase offsets,
and is used cyclically to specify an offset for each and every PHA <value>
in the <paffile>. If the <ddslist> refers to more than one DDS unit, then the
same offset is applied to all the DDS units at any given block number. The
phase offsets can be specified either as physical phase angles or as HW integer
phase values, encoded in the same way as the <PHA values> in the <paffile>.
There will never be an overflow, for the result is always calculated modulo
360 degrees. If both <paffile> and <phaseoffsetlist> specify values in HW
integers (0x...), then the new phase is calculated using integer arithmetic.
If either or both are specified in the physical float format, then the offset
is calculated by first converting both values to physical values (doubles) and
doing the addition in floating point, and finally rounding the sum to a HW value.
Contrast this option with the option -c <phaseoffsetlist>. The option
-p <phaseoffsetlist>, separately for each DDS unit in the <ddslist>, applies the
offsets in <phaseoffsetlist> cyclically to all blocks (addresses) in the PAF file.
The option -c instead applies only a single, but dds-dependent, phase offset for
the whole PAF file. The first dds in the <ddslist> gets the first offset
in the <phaseoffsetlist>, the second dds in the <ddslist> gets the second offset
in the <phaseoffsetlist>, and so on. If the <phaseoffsetlist> is shorter than
the <ddslist>, the offset list is re-used cyclically as many times as necessary.
-> -c | -correct_dds_phase <phaseoffsetlist>. This option can be used to adjust
the <PHA value>s on per-dds-unit basis. See the previous option (-p) for
more details.
-> -f | -frequencyoffset <freqoffsetlist>. This option can be used to adjust the <FRQ
value>s in the <paffile> by adding values from the <freqoffsetlist> to the values
in the <paffile>. The <freqoffsetlist> is used cyclically if it contains less
entries than there are FRQ lines in the <paffile>. In the <freqoffsetlist>, the
offsets can be specified either as floats giving physical offset in MHz, or using
the HW format 0x..., analogously with the phases in <phaseoffsetlist>. Negative
offsets in HW format are expressed by using a minus sign in front of the 0xnnnn
string.
<ddslist> specifies the DDS units into who's RAMs the <paffile> (modified by the
options) is to be loaded. See e.g. sethamplitude for possible formats.
EXAMPLES
> loaddds myexp.paf t*"
> loaddds myexp.paf t1,2,3 -scale {0.5 0.6 0.7}"
> loaddds myexp.paf t1,2 -p {0 0 0 0 180 180 180 180}"
> loaddds myexp.paf -c t1,2,3 {354.0 57.2 18.6}"
> loaddds myexp.paf t1,2,3,4,5,6 -foff -0.001"
> loaddds /tmp/PAFfile_m1.sh m"
See also
ampgen mpvwrite
logtx
Write tx status to a log file and to a web page.
Synopsis
logtx ?-long|-short|-llong? ?<TxList>? ?-m <Message>?
logtx ?reload <Seconds>|off|get?
Description
TX status log is written to a daily TX log file in /kst/log/HOT/, and,
by default, also to a web page, currently at the URL
http://www.eiscat.uit.no/heating/h-status.html. The status written
to the log file can be in a "short" or "long" format, depending
on the flag -long|-short, the status in the webpage is always written
in a fixed (short) format, while the default format in file is -long.
-> <TxList> specifies which TX units t1...t12 are logged.
Default is to log all 12 units.
-> An optional <Message> can be added to the end of the status
printout by using the option -m. Note that the message can extended
over multiple lines.
-> When EROS boots, writing to the web page is on by default, but
can be turned off by setting the web page's auto-reload time
to zero, or to the value "off", by using the subcommand reload.
Current auto-reload interval in seconds can be queried as
logtx reload get. The reload interval can be set to any value
larger than a minimum which is currently hardcoded to 5 seconds.
Initial reload interval is defined in the Eros [eGet] database
by the entry h_status_web_updatesec, currently 20 seconds.
-> Note that the auto-reload refers to the automatic reloading
of the web page only; the contents of the web page are not
updated automatically, but only as a consequence of the
logtx or printtx commands (which, in the very minimum,
results in a new time stamp on the web page). To save effort
of the user's
browser and the site's web server, it may make some sense to
turn off auto-reloading when an experiment is not running, by using
logtx reload off.
Examples
> logtx
=> write tx status to tx log in the short format, and,
possibly, to a web page in a fixed format.
> logtx -m "This is a test message"
> logtx -m "This is a test message
: on two lines"
> logtx -long
> logtx reload get
==> returns current auto-reload time of the web page.
> logtx reload 30
==> set auto-reload time to 30 seconds
> logtx reload off
==> turn off the web page auto-reload feature
> logtx reload fast
==> set auto-reload interval to the minimum value (5 sec).
move_c1_down
Starts moving c1 (the 'tuning' vacuum capacitor) towards a lower value.
Synopsis
move_c1_down <tx list>
Description
Starts moving c1 towards a lower value.
Equivalent to pushing the grey '-CT' button in manual mode.
Use stop_c1c2 to stop moving.
(This command will also stop c1 moving if it is moving up. But then
a stop_c1c2 command is necessary to enable further movements)
move_c1_up
Starts moving c1 (the 'tuning' vacuum capacitor) towards a higher value.
Synopsis
move_c1_up <tx list>
Description
Starts moving c1 towards a higher value.
Equivalent to pushing the grey '+CT' button in manual mode.
Use stop_c1c2 to stop moving.
(This command will also stop c1 moving if it is moving down. But then
a stop_c1c2 command is necessary to enable further movements)
move_c2_down
Starts moving c2 (the 'matching' vacuum capacitor) towards a lower value.
Synopsis
move_c2_down <tx list>
Description
Starts moving c2 towards a lower value.
Equivalent to pushing the grey '-CM' button in manual mode.
Use stop_c1c2 to stop moving.
(This command will also stop c2 moving if it is moving down. But then
a stop_c1c2 command is necessary to enable further movements)
move_c2_up
Starts moving c2 (the 'matching' vacuum capacitor) towards a higher value.
Synopsis
move_c2_up <tx list>
Description
Starts moving c2 towards a higher value.
Equivalent to pushing the grey '+CM' button in manual mode.
Use stop_c1c2 to stop moving.
(This command will also stop c2 moving if it is moving down. But then
a stop_c1c2 command is necessary to enable further movements)
mpvwrite
Write a word directly to the I/O interface of Heating exciter,
OR "execute" a script containing mpvwrite commands.
Synopsis
mpvwrite ? Flags ? -b <basechannel> -d <dataword> (1)
mpvwrite ? Flags ? -f <infile> ? -B <boardindex> ? (2)
Description
Mode (1):
-> This command directly executes the unix command-line
command mpv_write in the EROS VME process.
-> The command selectddsboard must be used earlier to
select the DDS board for which this command applies.
Mode (2):
-> The command executes a script containing mpv_write commands
in the EROS VME process. The script name is given via the -f switch.
-> If the -B <boardindex> option is used, the <infile> is modified
in flight so that the board-selection commands in the file will
refer to board number <boardindex>. Boardindex 0 means the master
board (m), and indexes 1 to 6 mean the boards b1...b6.
Common flags:
-T: Testmode (this options is always on in EROS simulator)
-i: Initialize the heating MPV board before write.
-w: Wait for the DDS interface to become available (at the
end of current integration period, if the TX R/C is running).
-v: Verbose output into EROS vme window.
See also
selectddsboard
pc_control_off
Alias to computer_control_off
pc_control_on
Alias to computer_control_on
petclearcommandqueue
Delete the command file cmnd.dat and its lock in the Heating PET.
Synopsis
petclearcommandqueue
Description
This command is for maintenance and EROS simulation use. Normally,
the running pet program removes the command file. During simulation,
this may not happen automatically.
petgetfile
Copy a file from Heating PET to the EROS computer.
Synopsis
petgetfile SourceFile DestFileName
petgetfile SourceFile DestDirName
Examples
petgetfile C:\unix\Stat-cmd.dat ~/desktop/
petls
List filenames on the Heating PET computer.
Synopsis
petls Pattern
See also
petpwd [ petputfile] petgetfile
petputfile
Copy a text file from the EROS computer to the Heating PET computer.
Synopsis
petputfile Source Dest
Description
-> Transfer a text file from the computer that runs the main part
of EROS (in particularly, the computer that runs EXPRUN), to
the PET computer. The transfer automatically handles end-of-line
conversion between UNIX and Windows.
-> Source must specify a unique file name in the EROS computer.
-> Dest must specify either a unique directory, or a unique filename
in the PET computer.
-> The transfer is done using the same EROS "Send" command
that is used for EROS interprocess messaging. Don't try to
transfer very large files using this command.
-> Note that the default working directory in the PET is
C:\unix in rt-mode, and /kst/eros4/pet in normal simulation mode
in a unix box.
Example
petputfile /kst/eros4/pet/petlib.tcl .
See also
petgetfile petls petpwd
petpwd
Print EROS working directory in the Heating PET computer.
Synopsis
petpwd
Description
Print out the current directory as maintained of the
EROS process running in the PET computer. Normally, or
EROS processes (give the impression that they) run in the
same directory, which can be displayed by the standard pwd
command. But as the PET windows computer has an entirely different
directory structure, this option is not practical now. Especially,
the normal Eros command "cd" has does not effect the Eros process
running in the PET. Normally, the command should return "C:\unix".
See also
petls petgetfile petputfile
power_level_1
Sets measurement range of RF amplitude suitable for < 50kW.
Synopsis
power_level_1
Description
Sets the gain appropriately in the transmitter RF output measuring
circuit for the 'amplitude matching' feedback loop for power levels <50 kW.
A faint light becomes visible on the grey '50 kW' button.
Common command to all transmitters. Default should be power_level_2.
power_level_2
Sets measurement range of RF amplitude suitable for > 50 and < 100kW.
Synopsis
power_level_2
Description
Sets the gain appropriately in the transmitter RF output measuring
circuit for the 'amplitude matching' feedback loop for power levels
> 50kW and <100 kW.
A faint light becomes visible on the grey '100 kW' button.
Common command to all transmitters. Default value.
power_level_3
Sets measurement range of RF amplitude suitable for >100 and < 130kW.
Synopsis
power_level_3
Description
Sets the gain appropriately in the transmitter RF output measuring
circuit for the 'amplitude matching' feedback loop for power levels
>100 kW and <130 kW. Never used since most tx modules cannot deliver > 100kW.
A faint light becomes visible on the grey '130 kW' button.
Common command to all transmitters. Default should be power_level_2.
powercal
Set and query power calibration info.
Synopsis
powercal info
powercal get ?<txlist>?
powercal set <pcalfile>
powercal reset | factoryreset
Description
-> Power calibration specifies the conversion to be used from exciter amplitude
values to kilowatts and vice versa. The calibration relation is initialized at
EROS boot time, either to hardcoded "factory defaults", or, if the
entry "pcalfile" has been defined in boot_config and is non-empty, to the
values defined in the pcalfile.
-> powercal info
This subcommand returns the current calibration source.
-> powercal get ?<txlist>?
This subcommands returns a dictionary which gives the calibration
curves for the transmitters given in the <txlist>, e.g. t1 t2. If
<txlist> is not given, all is assumed.
-> powercal set <pcalfile>
Start using calibration defined in <pcalfile>.
-> powercal reset
Start using calibration defined in the file "[eGet] pcalfile",
or the hardcoded defaults if pcalfile is not defined in the boot_config.
This is the initial calibration specification after Eros bootup.
-> powercal factory
Start using the hardcoded calibration.
-> The three ways of setting the calibration source are used in a hierarchical way
starting from factoryreset and ending in set pcalfile.
The factoryreset settings are hardcoded for all twelve transmitters in the
routine HOT_InitAmp2Pow in the file libheat/heating.tcl. Instead, the pcal
files need not specify all transmitters: For the missing tx, values from lower
level in the hierarchy are used. That is, when using "set <pcalfile>", if,
say, t10 is not specified in the file, Eros picks the t10 calibration from
the "[eGet] pcalfile" file if it exists and specifies t10, else Eros uses the
hardcoded specification for t10.
-> FORMAT OF THE CALIBRATION FILE
The calibration file should have file extension .pcal, but that is not
enforced. The format of the power calibration file should be as follows, though
the format is not checked rigorously yet.
First, there must be a four-line header, where each line begins with a keyword.
The lines must be in the expected order, but there can be empty lines and comment
lines, starting with # or %, freely interspersed.
CALPOWER 1.0
DATE <anything -e.g. DD-MMM-YYYY HH:MM:SS.d>
INFO <anything - e.g. how this calibration was done >
COLUMNS <anything - e.g. the names of the columns >
After the header can come any number of lines specifying the calibration curves for
a number of transmitters. The required format of each line is
t<n> <amplitude value> <power value in kW> <anything>
The transmitter number, <n>, is one of 1...12, and must not decrease from line to
line. For a given t<n>, both the <amplitude value> and the <power value> must
increase from line to line, so that the calibration curve will be a monotonously
increasing function so that it can be inverted. The first point must be (0 0), the
last point must correspond to maximum "useful" amplitude, that is, a value which
already gives (a desired) maximal power. The sethamplitude and changehamplitude
commands in kW mode respect these limits so that the amplitude never goes outside
the calibration curve limits in that mode. Also, printdds never shows the
power being outside of the calibration curve limits, even if the amplitude might be
outside the upper calibration limit.
If an <amplitude_value> on a line is -1, that line is checked for syntax, but is
otherwise ignored.
See also
sethamplitude changehamplitude printdds
printbeam
Print info about the started Heater beams.
Synopsis
printbeam <Name> ?OPTIONS?
Description
<Name> is name of a started beam.
OPTIONS
-beam: Show the Beam Table.
-dds: Show the DDS Table.
-def: Show the beam-forming parameters.
-command: Show the command string used to create the beam defition.
-v: Verbose mode.
See also
Use "[beam] info" to show info about any beam currently defined in EROS.
printbeam2
Print info about the latest activated heater beam.
Synopsis
printbeam2 ?OPTIONS?
Description
...
See also
Use "[beam] print" to show info about any beam currently in memory.
printdds
Return|print DDS amp, pha, and freq parameters.
Synopsis
printdds ?<Format>...? ?<ddslist>? ?<Item>...? ?<Numeric>? ?>|>> <FileName>?
Description
Print out the last set DDS amp, freq and phase for each DDS unit.
What is actually printed are only the values of the above variables as
known to EROS. The values become known to EROS when the values are set
using the sethamplitude, sethfrequency, and sethphase commands,
or the dds command, or the changehamplitude command. EROS does
not maintain these values over reboot even though the
hardware may well do. Values not set in current session of EROS
are printed out as "?". Also note that when the DDS operates from
the amplitude RAM, the amplitude values printed here may have no
connection to the actual amplitude values, but no warning is given.
-> <Format> is one of the following
-x: Print amp, freq and phase in hexadecimal as stored internally
in the DDS hardware.
-f: Print amp, freq and phase in "physical" units, so that the
amp is float between 0 and 1, freq is in MHz, and phase in
decimal degrees.
-dB: Same as -f, except that instead of amplitude, the corresponding
output power is shown in dB relative to the maximum output
power. Note that the legal value amp=0 is printed out as "-inf"
in this format.
Default <Format> is -f.
-> <ddslist> is as in sethamplitude.
-> <Item> is pha, amp, pow, or freq.
-> If <Numeric> is either "-numeric" or "-dict", the info are returned as
a nested dictionary.
There is one sub-dictionary for each DDS units in the DDS list,
with name t1 ... t12, m1, m2. Each of the sub-dictionaries has one
or more of the fields
xamp amp amp_dB xfrq frq xpha pha,
depending on the FORMATs and the lists of ITEMs. The fields xamp, xfrq
and xpha are the "native", encoded hex format hardware values, and are
included if the format -x is included in the FORMAT list. The fields
amp, frq and pha are amplitude between 0 and 1, frequency in MHz and
phase in degrees, respectively.
if <Numeric> is set to "-list", the info are returned as a number
of lists, one for each ITEM. The lists are of the form
key value key value ...
Where key is one of m1 ... t12, and the value is the appropriate
value using <Format>. Only one format at a time is allowed with "-list".
-> It is also possible to redirect the command output to file <FileName>
using the standard unix redirections symbols ">" for overwrite and
">>" for append.
Examples
printdds
printdds -x
printdds -x -d
printdds pow t*
printdds t1,2,3,4 m* amp
set D [printdds -num t* -dB]
set t2_amp_dB [dict get $D t2 amp_dB]
set t1_pha [dict get $D t1 pha]
array set A [printdds -list amp]
set A(m2)
printdds > mylog.log
See also
printtx printbeam gethamplitude
printtx
Show status of Heating transmitters.
Synopsis
printtx ?-numeric? ?-printable? ?-long? ?-long -long? <TxList>?
Description
-> Get status of the heating transmitters. At least the measured Phase, SWR,
and Power for each transmitter 1-12 are returned.
-> Without any flags, the status of all transmitters is returned as
a formatted, printable multi-line string.
-> The flag -long causes a "long" printout, which in addition to the
Phase, SWR and Power also contains another Power estimate, two
cap values, and the actually measured forward and reverse phases. Finally,
also DDS samplitude and phase are included, as kept by Eros.
-> The repetion of flag -long, as "-long -long" (or as "-ll"), does everything
that long does, and in addition shows the tx buttons state.
-> If both -numeric and -printable are used, a two element list is
returned, where the first element contains the printable string, and
the second element the numeric dictionary. Note that the dictonary returned
when using -numeric may not have all the items present in the printout.
-> If the flag -numeric is used, the transmitter info is returned
as a tcl dictionary data structure, with the following
fields (the fields marked with "L" below are only returned when the
flag -long is also used).
* tstamp "28-Jun-2009 13:40:56"
* t1
...
* t12
Each of the fields tK is itself a dictionary, with the fields
* stat ok|err
* msg if stat=='err', contains an error message,
else this field is missing.
* frq frequency in MHz
* arr A1|A2|A3
* pha in degrees
* swr standing wave ratio
* pow power in MW
* powa (L) power in MW
* cap1 (L) cap in nF
* cap2 (L) cap in nF
* fpha (L) forward phase in degrees
* rpha (L) reverse phase in degrees
Examples
printtx
printtx t1,2,3,4
printtx -long -long
set x [printtx -num -long]; set pha10 [dict get $x t10 pha]
See also
printdds
psoff
Load and leave running a rec RC program to turn Heating powersaving OFF.
pson
Load and leave running a rec RC program to turn Heating powersaving ON.
pushbutton
Change Heating transmitter button-state, as if when bushing a console button.
Syntax
pushbutton ? <TxList> ? <Button>
pushbutton ?t0? wn|wf|vh|vn|vf|hn|hf
Description
The Heating TX console has a set of pushable buttons for each of the 12
transmitter units. Traditionally, the operator has pushed these manually
to change the module state. pushbutton now allows this to be done from EROS.
pushbutton ultimately invokes the Unix-level program bushbuttons,
whose C-source is in EISCAT CVS in the module "hxconsole". The Unix
program "transmitters" must be running.
-> <TxList> specifies the affected transmitter modules e.g. t1,2,3,4 or t1 t2 t2 t4.
If <TxList> is missing, all transmitters is implied.
-> For t1,...,t12, <Button> can be
sf standbyoff
sn standby standbyon
ff filoff filamentoff
fn filon filament filamenton
pf plateoff hvoff
pn plateon plate hvon
a1 arr1 array1
a2 arr2 array2
a3 arr3 array3
b1 band1
b2 band2
b3 band3
-> For t0 <Button> can be
wn ==> water pump on
wf
vh ==> ventilation fan half speed
vn ==> ventilation fan normal speed
vf ==> ventilation fan off
hn
hf
-> The button presses must proceed in specific order, failing to do so
will result in an error.
See also
readlights
read_c1
Read cap 1 values from selected tx modules.
Synopsis
read_c1 ?-raw? <tx list>
Description
Return a list of cap 1 values.
Position of "frequency tuning" vacuum capacitor C1 is returned in pF.
It is digitised in the transmitter using 8 bits.
The -raw option gives the corresponding bit pattern (0 to 255).
See also read_c2, move_c1_up, move_c1_down, stop_c1c2,
set_c1, setcapacitor
read_c2
Read cap 2 values from selected tx modules.
Synopsis
read_c2 ?-raw? <tx list>
Description
Return a list of cap 2 values.
Position of "amplitude matching" vacuum capacitor C2 is returned in pF.
It is digitised in the transmitter using 8 bits.
The -raw option gives the corresponding bit pattern (0 to 255).
See also read_c1, move_c2_up, move_c2_down, stop_c1c2,
set_c1, setcapacitor
read_epsilon
Reads the feedback error status of both tuning and matching circuits.
Synopsis
read_epsilon <tx list>
Description
Return eps list. At the moment, just the raw byte values.
Indicates when the red console light labelled 'eps > eps_max' is lit,
which means that the error signal from either of the tuning or matching feedback
loops in the auto-tuning circuits is greater than some maximum value.
It also indicates when an external capacitor move command is given.
Returned values are:
255 (11111111) when the power to a transmitter module is off
247 (11110111) when the power to a transmitter module is on (both "int" and "ext" on txmodule)
241 (11110001) when power is on and epsilon light is on (eps > eps_max) on its own transmitter
243 (11110011) when power is on and (eps > eps_max) on another transmitter,(eps > eps_max)
251 (11111011) when power is off and (eps > eps_max) on another transmitter, (eps > eps_max)
read_forward_phase
Read forward phases from selected tx modules.
Synopsis
read_forward_phase ?-raw? TxList
Description
Return a list of forward phases in degrees.
Phase of the forward wave to the antenna, measured at a coupler on the
co-axial cable output of the txmodule, with respect to a reference frequency
from DDS m1 or m2. It is digitised with 8 bits in the transmitter.
read_forward_rf_voltage
Read forward voltages from selected tx modules.
Synopsis
read_forward_rf_voltage <tx list>
Description
Return a list of forward voltage numbers (arbitrary scale).
Amplitude of the forward wave to the antenna, measured at a coupler on the
co-axial cable output of the txmodule, with respect to a reference frequency
from DDS m1 or m2. It is digitised with 8 bits in the transmitter.
See also read_forward_phase
Example
read_forward_rf_voltage t1 t4,5,6 t2
read_reverse_phase
Read reverse phases from selected tx modules.
Synopsis
read_reverse_phase ?-raw? TxList
Description
Return a list of reverse phases in degrees.
Phase of the reflected wave from the antenna, measured at a coupler on the
co-axial cable output of the txmodule, with respect to a reference frequency
from DDS m1 or m2. It is digitised with 8 bits in the transmitter.
read_reverse_rf_voltage
Read reverse voltages from selected tx modules.
Synopsis
read_u_reverse TxList
Description
Return a list of reverse voltages (arbitrary scale).
Amplitude of the reflected wave from the antenna, measured at a coupler on the
co-axial cable output of the txmodule, with respect to a reference frequency
from DDS m1 or m2. It is digitised with 8 bits in the transmitter.
read_txpower
Read analogue power from selected tx modules.
Synopsis
read_txpower ?-raw? <tx list>
Description
Return a list of power values, either in kW, or in raw (byte), units.
Output power from the txmodule in kW. It is calculated using analogue
electronics in the transmitter from the forward and reverse voltages
measured at the output coupler (= U2v-U2r). It is digitised in the
transmitter using 8 bits.
readhall
Return info about Heating water pump, fans, etc, from tx hall.
readlights
Return info about Heating transmitter console buttons' states.
Synopsis
readlights ?<Tx list>? ?<Button>? ?<Button>...? ?-long|-numeric?
Description
Each of the 12 transmitters has a set of console buttons for control
and monitoring. readlights returns the state of some or all of them.
readlights ultimately invokes the unix-level program readlights, which
has its C-source in EISCAT CVS as the module "hxconsole". readlights also
requires that the "transmitters" unix-level program is running.
<Tx list> :
Specifies the TX units, e.g. as t1,2,3,4 or t1 t2 t3 t4.
If none are explicitly given, "all" is implied.
<Button> :
Button name. If none is given, all is implied.
Supported button names include (but are not restricted to -- longer names
can also be used) the following:
[*] a b sf sn ff fn pf pf a1 a2 a3 b1 b2 b3 df dn in ad ep th
The button names are case-insensitive. The button names are parsed
by the routine HOT_pick_buttons in the file libheat/txio.tcl, which can be
consulted for further details. See also the examples below.
-> Most of the button names in [*] are just names for the individual buttons.
The button names "a" and "b" are special shorthands for the overall
"array" and "band" states of the TX units. What happens when those two
are used as button names depends upon whether -long is used or not:
If -long format is used, "a" is aquivalent to specifying a1 a2 a3 and
"b" is equivalent to specifying b1 b2 b3, so three bit values 0 or 1 are
returned both for "a" and "b".
If -long is not used, _any_ of the array state requests a, a1, a2 or a3
just returns A<n>, where <n> is 1, 2 or 3 depending which array is being
connected to the TX unit in question. The array state can be also in transition
between the three possibilities, in which case just "A" is returned.
If -long is not used, _any_ of the array state requests b, b1, b2 or b3
just returns B<n>, where <n> is 1, 2 or 3 depending which band is used
for the TX unit in question. The band state can be also in a (rather slow)
transition between the three possibilities, in which case just "B" is returned.
-> Several TX subsystems have two buttons for control, one for turning something on,
the other turning it of. What readlights reports about these depends whether -long
is used or not. If -long is used, as e.g.
readlights fn -long,
the command returns 1 if the filament-on button is ON, and 0 if it OFF, and similarly,
readlights ff -long tells what is the state of the filament-off button's light.
If -long is not used, then both
readlights ff
and
readlights fn
return the TX state (rather just the button's state), as either "ff" (filament is OFF)
or fn (filament is ON) or just "f" (system inactive).
(But there are exceptions to this behaviour.)
-numeric :
The results are returned as a list of lists, each one giving
the state of the requested buttons for one TX unit.
If -numeric is not used (the default), the results are returned as a single
string which in interactive use gets then printed to the terminal.
Note that if -numeric is used, -long must not be used.
-long :
If the -long option is used, results are returned as appropriately
filtered version of the full decoded output of the unix level "readlight -l" command,
which return a full status of all buttons of all transmitters as a long string of
lines, each of the form
tn Button 0|1
The LONG format does not support -numeric.
Examples
readlights
==> Return a button-state of all transmitters in a short form, e.g.
t1 2 3 4 5 6 7 8 9 10 11 12
------------------------------------
sf sf sn sf sf sf sf sf sf sf sf sf
f ff fn f f f f f f f f f
p p pn pf p p p p p p p p
A1 A2 A1 A1 A1 A1 A1 A1 A1 A1 A1 A1
B1 B1 B1 B1 B1 B1 B1 B1 B1 B1 B1 B1
df df df df df df df df df df df df
i i i i i i i i i i i i
a a a a a a a a a a a a
e e e e e e e e e e e e
t t t t t t t t t t t t
readlights t1 -long
==> Return every buttons' state for transmitter unit 1 in long format.
t1 StbON 0 # button names: sn, stb, stbon, standbyon
t1 FilOFF 0 # button names: ff, filoff, filamentoff
t1 FilON 0 # button names: fn, filon, filamenton
t1 PlaOFF 0 # button names: pf, plateoff, hvoff
t1 PlaON 0 # button names: pn, plateon, hvon
t1 Array1 1 # button names: a1, arr1, array1
t1 Array2 0
t1 Array3 0
t1 Band1 1 # button names: b1, band1
t1 Band2 0
t1 Band3 0
t1 Driver 0 # button names: dn, driveron
t1 Intern 0 # button names: in, int, internal
t1 Adjust 0 # button names: ad, adj, adjustment
t1 E>Emax 0 # button names: ep, eps, e>emax
t1 Y>Ymax 0 # button names: th, theta, y>ymax
readlights arr band driver -numeric
==> Return array, band and driver state of all 12 TX units as a list of 12 sub-lists
{A1 B1 df} {A2 B1 df} {A1 B1 df} {A1 B1 df} ... {A1 B1 df}
See also
pushbutton
rfoff
Load and leave running a tra RC program to turn Heating RF OFF.
rfon
Load and leave running a tra RC program to turn Heating RF ON.
savecaps
Read caps from HW and save to file.
Synopsis
savecaps ?TxList? ?CapsFile?
Description
-> <TxList> is of the form "t<n> t<n> ...", or "all". Default is "all".
-> <CapsFile> default is specified in boot_config.tcl, and can be found
at runtime using EROS online help or by the command "eGet capsfile".
-> <CapsFile> must have extension ".caps" and must have one of the following formats.
-> Basic format is just two lines, listing the caps in pF for each 12 tx units, e.g.
205.9 282.4 300.0 270.6 288.2 229.4 176.5 252.9 252.9 205.9 247.1 252.9
454.9 431.4 345.1 329.4 423.5 478.4 486.3 321.6 462.7 454.9 447.1 360.8
-> Other formats are of the form
CAPS <version>.<subversion>
DATE <date string>
C1 <caps value list>
C2 <caps value list>
and may contain more lines. The lines C1 and C2 contain list of 12 caps values,
where any value less than 10 means the value is "invalid" so that loadcaps will not
use it.
Examples
savecaps
savecaps t1 t2 t3 t4
savecaps mycaps.caps
See also
loadcaps
selectddsboard
Select a Heating exciter board for future I/O operations.
Synopsis
selectddsboard BoardName | none
Description
-> Select one of the 7 a heating DDS boards b1, ... b6 or m.
-> Use "none" to deselect (all) boards.
-> Note that a LED on the board's front panel shows when
the board is selected.
Examples
selectddsboard board2
See also
deselectddsboard
set_c1
Set cap 1 on selected tx modules to given values.
Synopsis
set_c1 ?<OPTIONS>? <tx list> <cap list> ?<tx list> <cap list> ...?
set_c1 ?<OPTIONS>? <cap>
Description
-> The default input mode for <cap> values is in integer picofarads. This
can be changed to raw byte value 0...255 by using the option -raw.
-> In the first form of the command, equal number of tx and caps must
be explicitly specified.
-> The latter form of the command sets all caps to the given <cap> value.
-> The return value is as follows:
From fox, we get a stat list, one stat for each tx in <tx list>.
We format that list like this:
In non-verbose mode:
** If no errors|timeouts, return a single "ok".
** If errors|timeouts, return full status list.
In verbose mode:
** Always return full status list
The full status list is of form
{stat stat ... stat},
where each stat is either "ok" (0) or "err" (1)
** Note that even if there are err's among the stat's,
the tcl-status of the whole command will still be 0,
so that a tcl error exception is not raised.
OPTIONS
-raw: Input cap values as raw bytes 0...255, by default,
pF's are used.
-slow: Move in slow mode.
-fast: Move in fast mode, This is the default.
-verbose: Always output full status list. Default is to
output only a single "ok" if no errors.
Examples
set_c1 t1 500 t2 600 t3 700
set_c1 t1,2,3 500 600 700 t4 800
set_c1 -raw 255
==> sets all to max
See also
set_c2 set_c1c2 setcapacitor
set_c1c2
Set caps 1 and cap2 on selected tx modules to given values.
Synopsis
set_c1c2 ?<OPTIONS>? <tx list> -c1|c1 <cap1> <cap>...? -c2|c2 <cap2> ?<cap2>...?
set_c1c2 ?<OPTIONS>? <tx> <cap1>,<cap2> ?<tx> <cap1>,<cap2> ...?
Description
-> The tx units and cap values can be specified in the above two forms, but in both
cases, equal number of tx units, cap1 values and cap2 values must be specified.
-> TxList : e.g. t1,2,3 or t2 t2 t3 or t1,t2,t3.
-> The command returns status in the same form as the setcapacitor command.
OPTIONS:
-raw : Cap values are in raw byte values. Default is (integer) picofarads.
-slow: Use slow cap speed. Default is to use high speed.
-verbose: Verbose return value. Default is non-verbose, in which case
only "ok" is returned if there are errors or timeouts.
Examples
-> set_c1c2 t1,2,3 -c1 500 500 700 -c2 550 660 770
-> set_c1c2 t1 500,550 t2 600,660 t3 700,770
-> set_c12c2 -slow 0,0
See also
set_c1 set_c2 setcapacitor
set_c2
Set cap 2 on selected tx modules to given values.
Synopsis
set_c2 ?<OPTIONS>? <tx list> <cap list> ?<tx list> <cap list> ...?
set_c2 ?<OPTIONS>? <cap>
Description
-> The default input mode for Cap values is in integer picofarads. This
can be changed to raw byte value 0...255 by using the option -raw.
-> In the first form of the command, equal number of tx and caps must
be explicitly specified.
-> The latter form of the command sets all caps to the given Cap value.
-> The return value is as follows:
From fox, we get a stat list, one stat for each tx in TxList.
We format that list like this:
In non-verbose mode:
*> If no errors|timeouts, return a single "ok".
*> If errors|timeouts, return full status list.
In verbose mode:
*> Always return full status list
The full status list is of form
{stat stat ... stat},
where each stat is either "ok" (0) or "err" (1)
> Note that even if there are err's among the stat's,
the tcl-status of the whole command will still be 0,
so that a tcl error exception is not raised.
OPTIONS
-raw : Input cap values as raw bytes 0...255, by default,
pF's are used.
-slow : Move in slow mode.
-fast : Move in fast mode, This is the default.
-verbose : Always output full status list. Default is to
output only a single "ok" if no errors.
Examples
-> set_c2 t1 500 t2 600 t3 700
-> set_c2 t1,2,3 500 600 700 t4 800
-> set_c2 -raw 255
==> sets all to max
See also
set_c1 set_c1c2 setcapacitor
setcapacitor
Adjust the tuning/matching capacitors on specified Heating TX modules.
Synopsis
setcapacitor ?-slow? ?-verbose? TXLIST CAPSPEC ?TXLIST CAPSPEC ...?
Description
-> The transmitter tuning/matching capacitor values are specified via
the CAPSPEC, which specifies both the frequency
band ("B1", "B2" or "B3") and the transmission frequency (in MHz),
for example, as "B2,4.74".
This info is then used to calculate the capacitor values that
are actually set to the hardware.
-> TXLIST is of the form tN,N,..., N=1-12, or TXLIST = "all".
-> By default, the "fast" mode of capacitor motion is used, the
switch -slow changes this (this option has effect only when
using the fox txio interface).
-> The -verbose option causes per-module status information to
be returned as a list like {{1 ok ok} {2 ok err} {3 ok ok}}
where the first element in the sublists is module number (1..12),
the second item cap1 status (ok|TO) and the third item cap2 status.
If the verbose option is not used, then:
In case everything went alright, only the string "ok" is returned,
but in case of any timeouts or errors, the full status is
returned. (This output format is for the FOX interface only).
Examples
setcapacitor all B2,4.74
setcapacitor t1 B2,4.74
setcapacitor t1,2 B2,4.74 t3,4,5,6,8 B2,4.02 t9,10,11,12 B2,4.74
See also
set_c1 set_c2 set_c1c2
sethamplitude
Set amplitude scaling factors on the Heating exciter.
Synopsis
sethamplitude ?OPTIONS? ?<ddslist>? <amp>
sethamplitude ?OPTIONS? <dds> <amp> ?<dds> <amp>...?
Description
Set the amplitude scaling factor (ASF) on a DDS unit.
-> <dds> is one of m1, m2, t1, t2, ... t12
<ddslist> is a list of <dds>s or m* or t* or "all".
Some other short-hand formats are also allowed, see the examples.
Default is "all".
-> <amp> = 0...1 | -<x>dB | <x>% | <x>kW. (1)
<amp> = 0x<n>, where 0 <= <n> <=3FFF. (2)
-> The form (1) specifies a relative amplitude value between 0 and 1.
Amplitude with a kW unit cannot be used with m1 and m2.
It is possible to separate value and unit with spaces, but then
the value and unit must be bound together as e.g. "-3.5 dB" or {-3.5 dB}.
An amplitude value 0...1 for <x>kW is computed by the routine HOT_Pow2Amp,
currently based on calibration data hardcoded in the routine HOT_InitAmp2Pow.
-> The form (2) is used directly as a hex-encoded HW value.
-> The relation between the relative value 0...1 and the HW value is
<hw_value> = round(<rel_value> * 0x3FFF)
OPTIONS
-check: Check the command syntax and return the implied HW value of the amplitude
(hex in the range 0...3FFF). Exciter HW is not touched.
-deselect: Ensure that none of the accessed boards is left in the SELECTED state. Default
is to leave the last accessed board to the SELECTED state. This is, in the
case that only a single board is being accessed, to allow other commands to be issued
to that board without the need to wait for it to become re-selected, see "-nowait".
If no such access is required, -deselect should be used to release the board for
RC's use. This can equivalently be done by using the separate deselectddsboard command.
-nowait: Do not perform RUNWAIT when writing to the DDS. Default is to do a RUNWAIT,
that is, to wait for the board where the DDS sits to become selected. With the TX RC
running, the board becomes selected only at the end of the integration period during
during which the sethamplitude command is given; or after a timeout, which currently has
been hardcoded to (about) 15 seconds in the subroutine run_valid() in the file
eros5/heating/src/ddslib.c. But if a timeout occurs, the command most probably fails.
For, if the board is not in the selected state at the instant of time when the DDS module
itself is accessed via a dds_write(), the access route to the DDS module is blocked, and
the command will silently (!!!) fail.
So normally, -nowait should not be used when the TX RC is running. The -nowait flag
gives not much gain even if the TX RC is not running. For then, the board becomes selected
immediately when the sethamplitude starts executing, and even though, without -nowait,
there would be a call to run_valid(), that call would incur very little extra execution time.
Note that the rather short RUNWAIT timeout, which, as explained, should not be
allowed to expire, results in some limitations about precisely at what instant of
time sethamplitude can be successfully given if the TX RC integration period is longer
than that timeout time: First, the command must be given within the timeout time before
the end of the integration period, but second, the command must also be able to complete
for all required boards before the end of the integration period. Typically,
sethamplitude takes about 0.3 sec per DDS unit.
-timestamp: Add microsecond-scale timestamps to the dds_write and mpv_write commands
echoed in the EROS VME window during the command's execution.
-verbose: Verbose output to the EROS VME window.
-wait: Perform RUNWAIT in dds_write() when writing to the DDS. This is the default. See -nowait.
Examples
sethamplitude 0 ;# set all
sethamplitude t1 0.3
sethamplitude m1 0.3 t1 0.8
sethamplitude -10dB ;# set all dds units
sethamplitude m2 t* 0.78 ;# set all except m1
sethamplitude 0x2d4e ;# use this directly as the HW value
sethamplitude m* t2,3 0.78
sethamplitude m1 m2 t2 t3 0.78
sethamplitude 10 kW ;# only affects t1 ... t12
sethamplitude t1 70kW t2 80kW
See also
changehamplitude sethfrequency sethphase printdds
sethfrequency
Set carrier frequency on one or more of the Heating exciter DDS units.
Synopsis
sethfrequency ?OPTIONS? <dds> <freq> ?<dds> <freq>...?
sethfrequency ?OPTIONS? <ddslist> <freq>
Description
Set the frequency turning word (FTW) on the specified DDS units.
-> <dds> and <ddslist> as in sethamplitude
-> <freq> is one of the following:
(*) A double number like 4.04 or 5. This is interpreted as
a frequency in MHz.
(*) A double number followed by a unit specifier, which can be
MHz, kHz or Hz. The value and unit must be bound together, e.g.
"4040 kHz" or {4040 kHz} or 4040kHz.
(*) A symbolic name F1 F2 ... F9, to denote the standard
Heater frequencies 4.04 4.544 ... 7.953MHz (see freqinfo).
(*) A C-language hex string like 0x1234. This is interpreted as
an encoded hardware value and must be between 0x0 and 0x80000000.
OPTIONS
-check: Check the command syntax and return the implied HW value of the frequency.
Exciter HW is not touched. Use -c -c or -C to also show the RF output
frequency with larger precision.
-deselect: Do a [deselectddspboard] in the end.
-nowait: Do not perform RUNWAIT in dds_write when writing to the DDS.
Normally, this flag should not be used. See sethamplitude.
-timestamp: Add microsecond-scale timestamps to the dds_write and mpv_write commands
echoed in the EROS VME window.
-verbose: Verbose output to the EROS VME window.
-wait: Perform RUNWAIT in dds_write when accessing the DDS. This is the default,
Examples
sethfrequency 4.04 ;# all DDS (including m1 and m2).
sethfrequency t1 5.4
sethfrequency m1,2 t1,2,3,4 4040kHz
sethfrequency t1 4.0 t2 4.01
sethfrequency m2 t* 4.04 ;# all DDSs except m1
sethfrequency m2 F1
sethfrequency t1 0x52bd3c3
sethfrequency t1 -C "5400 kHz" ==> t1 0x06e978d5 5.400000000372529
See also
dds syncdds setlo [setnco] [freq]
sethphase
Set phase offsets on the DDS units of the Heating exciter.
Synopsis
sethphase ?OPTIONS? <dds> <Phase> ?<dds> <Phase>...?"
sethphase ?OPTIONS? ?<ddslist>? <Phase>"
Description
Write the specified offset angle to the phase offset register of the specified DDS unit.
-> <dds> and <ddslist> as in sethamplitude.
-> <Phase> is either the offset angle in decimal degrees, or an encoded HW integer value.
The latter must be in a hex string starting with 0x or 0X,
and must be between 0x0000 and 0x3FFF inclusive. When using the decimal degree format,
any value is accepted but is mapped modulo 360 degr to 0...360-eps. The mapped value is
encoded to a 14-bit HW value via
<hwvalue> = round((<decimal_value>/360)*2^14).
-> If there are multiple <dds> specifications and a single <Phase> specification, all
the referred offsets are set to <Phase>. If there are multiple <Phase> specifications,
there must be an equal number of DDS unit specifications.
OPTIONS
-check: Check the command syntax and return the implied HW values of the phase
(hex in the range 0...3FFF). Exciter HW is not touched.
-Check: As -check, but also return the corresponding decimal degree value in high precision.
-nowait: The command does not check whether the DDS is really free to use
and accessible, and so the command can silently fail when the R/C is running. By default,
the command does wait for the DDS to be free to access. See sethamplitude.
-timestamp: Add microsecond-scale timestamps to the dds_write and mpv_write commands
echoed in the EROS VME window during the command's execution.
-verbose: Verbose output to the EROS VME window.
-wait: Perform RUNWAIT when writing to the DDS. This is the default.
Examples
sethphase 0
sethphase m* 0
sethphase t2 -90
sethphase m1 0x3000
sethphase t1,2,3,4 90
sethphase t1 90 t2 180 t3 90 t4 0
See also
sethamplitude sethfrequency
setlo
Set frequency of the Heating receiver local oscillator.
Synopsis
setlo Freq_MHz
setlo FreqName
Description
At Heating, there is strong interference from nearby transmitters. Also,
the band of the IF filter must be taken into account. One needs to optimize
the IF frequencies. The following Table gives the recommended settings for
the LO values and the corresponding values for the digital mixer (NCO) needed
for mixing the various heater RF frequencies to zero frequency.
FreqName = F1 ... F9
Name RF_freq LO_f NCO_f
--------------------------------
F1 4.040 16.5 12.460
F2 4.544 17.1 12.556
F3 4.9128 17.7 12.7872
F4 5.423 18.2 12.777
F5 6.200 19.0 12.800
F6 6.770 19.4 12.630
F7 6.960 19.4 12.440
F8 7.100 19.4 12.300
F9 7.953 19.8 11.847
See also
sethfrequency [setnco]
slow_capacitor_movement
Sets the capacitor speed to slow for both C1 and C2 for all transmitters.
Synopsis
slow_capacitor_movement
Description
Sets the speed of the tuning (C1) and matching (C2) variable vacuum capacitors
to slow for all transmitters. Equivalent to pushing the grey common button 'SLOW' in manual mode.
see also fast_capacitor_movement
startddsboard
Synopsis
startddsboard -ismaster boardname
startddsboard boardlist
Description
...
Examples
startddsboard -master board1
startddsboard board2
startddsboard board2,3,4,5,6,7
stop_c1c2
Stops both c1 and c2 moving.
Synopsis
stop_c1c2 <Tx List>
Description
Stops both c1 and c2 moving for a particular transmitter
and simultaneously disables 'auto-tuning' (orange 'ADJUSTMENT' light) feedback loops.
Effectively the same as the adj_off command.
Equivalent to pushing the black 'STOP' button in manual mode.
syncdds
Synchronize the Heating exciter DDS units.
Synopsis
syncdds ?-verbose? ? -phasereset ?
Description
-> Synchronize the DDS units m2 and t1-t12 to the master unit m1.
This is done by clearing the phase accumulators (but NOT
the phase offset registers), and then starting the
phase accumulation at the same instant of time on all the units
by a trigger from m1.
-> The command should be used each time the frequencies are changed
if one wants to keep the relative phases intact over the
frequency change (that if, if one wants to preserve the phase
coherence over the frequency change).
-> Use the flag -phasereset to set also the phase offset registers to
zero in connection of the sync. By default, phase reset to
zero is not done. If the -flag is used, EROS internal bookkeeping
now tracks the phase changes correctly.
Examples
syncdds
syncdds -phasereset
txmodule_status
...
Synopsis
txmodule_status ?-raw? <tx list>
Description
Return status list. With -raw, return the status byte values,
without (the default), return symbolic status list which currently
consists of either "ok" or "err" values.
If the interface is not under computer control (see computer_control_on)
this command returns 'ok' (255 in raw) which may be misleading.
txmodule_status -raw returns:
255 when the computer control is in 'manual'
Otherwise, when under computer control (orange 'PET' light lit) it returns:
0 when power to the transmitter module is off (Standby off)
0 when power is on (standby on) but transmitter is switched to "internal" in the transmitter hall.
255 when power is on (standby on) and transmitter is switched to "external" in the transmitter hall,
the normal operating mode.
So we cannot distinguish between the txmodule being powered off or
the transmitter being powered up locally in the transmitter hall.
Example
txmodule_stat -raw t1,4,12
==> {255 255 255}
txmodule_stat t1,4,12
==> {ok ok ok}