The siggen program can control up to 3 keysight
signal generators. It was first used for the nov18 hf
campaign. It replaced the autotoggle function from the original hf
gui (the autotoggle timebase drifted the longer you used it).
The program allows for the synchronization of the
hf and 430 pulses to the micro second level (ignoring pathlength
differences). To do this:
- the 430 tx
- uses a 10ms ipp (or something that divides into 1 sec)
- it is synchronized to the 1 second tick when started
- the keysight generators are synchronized by the hardware tick
(1 or 10 sec)
- the siggen program will:
- configure the signal generators
- use the computer clock to wait for say .1 sec after the 1
- then send a command for the generators to start on the next
The files used by the siggen program
There are 3 types of files used by the the siggen
program. They are all ascii files.
A command file might:
- command file:
- experiments are driven by a command file.
- It holds commands that siggen recognizes
- all other files are accessed through a command file.
- See below for a list of the commands
- config files:
- these contain scpi commands to send to a signal generator.
- they are executed using the config command in a command file
- A config file can be passed parameters from the config line
of the command file
- this allows a single config file to be used for multiple
- eg. if setting up burst mode, the pulse period and pulse
width could be parametrized rather than hardcoded.
- sequence files:
- Arbitrary waveforms are constructed in a sequence file.
- A command file loads states into the generator
- The sequence file combines these states to make a sequence
- states can be repeated
- sets of repeated states can be looped.
- define a number of variables
- configure a generator an config file, possibly passing
- define arbitrary states
- combine the states into a sequence.
- synchronize with the cpu clock , and then start the generators
running on the next hardware tick.
- optionally wait for the exp to finish (or return immediatley
to the siggen prog).
The siggen recognizes the following commands
in a command file:
- abbreviations used:
- sgnum : number for signal generator.. 1,2,3
- chan: channel in signal generator 1,2
- # in col one of any file (cmd, cfg, or .seq) is a comment
Command file commands.
|set var value
|set freq1 "5.095e6"
|set a variable to a value
|config 1 chirpcw.cfg freq1=$freq1
|calla config file
|arb sgnum chan
|arb 1 1 h5msl5ms h50 l50
arb 1 1 clr
arb 1 1 seq chirpcw.seq
|load state in gen
clr states,seq in gen
load seq in gen
|return .9 secs before next tick
|waitfor hhmmss tmBefore
|waitfor 162100 .9
|wait for 16:21:00 return .9 secs before.
|startsg sgnum chan type dur
|startsg 1 1 burst 1000
|start a burst setup. end after 1000 secs
|come back .5 secs before last startsg
|wait for 5.3 seconds
|log "start h3252"
|send string to log file
|terminp "switch to xmode"
|lets you put a delay in a command file.
When ready you must enter the string "go"
|on sgnum chan
|on 1 1
|turn on output for channel on siggen
|off sgnum chan
|off 1 1
|turn off output for channel on siggen
|send sgnum string
|send 1 SOURCE1:FUNC arb
|send scpi command to generator.
no reply allowed
- set var value:
- This lets you define variables in the command file.
- set sgArb 2
- set amp "4.3dbm"
- set freq1 "5.096e6"
- When accessing variable values in a command file, precede
the name with a $ (just like the shell)
- config $sgArb config ....
- The datatype for the variable is determined by the value
- quotes (' or ")--> string
- integer --> int
- float --> float
- Note that all values sent to a siggen are first converted to
- You should probably use strings when passing floating
point numbers to the siggen.
- "5.096e6" will pass this string exactly to the generator
- 5.096e6 will have to be converted by the program to a
string before sending to the generator.
- The program does not know the precision to use
when doing this conversion.
- Don't confuse variables with parameters.
- variables are defined and used in the command file
- parameters are passed to config files on the config line
- Inside config files, the parameters are also accessed via
- config sgnum file params
- execute a config file.
- set burstFreq "199.1"
- set pulsew ".001"
- set bcnt "199"
- config sgNum burst1.cfg
- The parameters are keyword=value
- multiple parameters are separated by a comma (no
embedded spaces allowed)
- In the config file, parameters can be accessed by
- SOURCE1:FREQ $freq
- SOURCE1:FUNC:PULS:WIDTH $pulsew
- SOURCE1:BURST:NCYCLES $bcnt
- all lines in the config file will be:
- parameters replaced with values
- then sent to the specified generator.
- All config files are currently relative
- That means you have to put all the config files below that
directory (this will eventually change)
- arb sgnum chan code args
- there are 3 separate arb commands .. specified in the code
- arb sgnum chan load arbNm args
- this loads states into a generator
- a state is a number of hi,low values.
- arbnm is the name of the state (to be used later by a
- args define the high, low durations (relative to the
sample clock..) for the state.
- arb 1 1 load h5ms5ms h50 l50
- if the sample clock was 100 usecs, this would be a 5
ms high, 5ms low
- The high, low sequence is first constructed in an array
in the program.
- the high count, low count is expanded to give that
number of hi's or lows.
- It is then sent to the generator using a binary xfer (so
it is pretty fast.. a million +points in less than a sec).
- The program sets a limit of 500 hN, LN entries per load
(this could be changed).
- there is a limit of about 4 million points in the
- I've been using a sample clock of 50 usecs to 1
- If you used a 100usec sample clock, the memory would
fill up after 400 seconds. So longer sequences need
- The drawback to a slower clock is:
- When starting on a hardware tick, the generator's
first output is 2 samples after the tick.
- With a slow sample clock, this can be a long delay.
- (this was true for the 2 older generators we
have. I need to check if the newer one is the same).
- The sample clock is normally defined in a config file,
this can be done after the arb load
- arb sgnum seq seqfile:
- this reads and loads a sequence file into the generator
- arb 1 1 seq grach/prog4.seq
- A sequence file is made up of sequence segments
- each sequence segment is made up of a arbState that was
defined with a arb load command.
- sequence file format
- col 1 defines the line type.
- N grachp4
- .. name of the sequence. used to access sequence
- s stateNm repeatCnt playControl markerMode
markerPos # comments
- defines a seqment. takes advantage of the looping
control built into the generator.
- s arbstart 1
20 # low 10ms then wait for tick to start
- s h70msi100ms 100
highAtStartGoLow 400 # h70ms l20ms h.05ms l9.95
- must already have been defined with: arb sgnum chn
- limited to 12 chars.
- how many times to repeat the state. Only used if
playcontrol is repeat
- once : play once
- onceWaitTrig : play once, then wait for trigger.
used to sync with tick
- repeat: repeat state using repeatCnt
- repeatinf: repeat forever
- the marker is used to trigger a scope on a portion
of a segment. It comes out on the sync bnc of the
- Markermode tells how this output changes in the
- maintain: stays the same
- lowAtStart: goes low at start
- highAtStart: goes high at start
- highAtStartGoLow: goes high at start, goes low
using the following field
- if highAtStartGoLow, this is the number of samples
after the start where the sync pulse goes low.
- the min value is 4 , the maxvalue is segmentLen
-3. so it screws up short segments..
- r repeatCnt
- Everything between the r and the following e line will
be repeated repeatcnt times
- This gives a second level of looping. It is done by
the siggen program.
- Repeat cnt must be <=50
- the entire sequence can not have more than 500
- Some gotchas.
- The generator memory value is used for the amplitude of
the state ,not the duration.
- we only use 0 and the max value for Low and High
- If you want a long arbitrary waveform, you can run out
of memory if you use a short sample time
- On the other hand, when starting on a tick, the output
occurs 2 sample clocks after the tick
- There is still some confusion with the order of things.
- When you specify the output voltage (in the
arb.cfg) the generator looks at the max,min value
in your arb waveform and scales things relative to the
max possible value.
- that means you have to define the arb waveform before
- and you have to tell the generator to be in arb
- So i think the order should be:
- arb xx clr .. clear the memory
- arb xx load .. define the states
- send xx source1:func arb .. tell
generator to go to arb waveform mode
- arb xx seq xx .. define the sequence
- config xx arb1_only.cfg .. do the
config for the sequence
- startsg xx xx seq:ArbName duration ..
use the seq:ARbName option to the start command
- arb sgnum chan clr
- clear the arbitrary waveform memory.
- This is important so you don't run out of memory.
<- page up