Heating Command Reference


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}