siggen programming

dec18

intro

Introduction:

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 sec tick
then send a command for the generators to start on the next hardware tick

The files used by the siggen program

There are 3 types of files used by the the siggen program. They are all ascii files.

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 setups
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 of states
states can be repeated
sets of repeated states can be looped.

A command file might:

define a number of variables
configure a generator an config file, possibly passing parameters
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).

Command files

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
dur:duration
# in col one of any file (cmd, cfg, or .seq) is a comment line.

**Command file commands.**
cmd	example	description
set var value	set freq1 "5.095e6"	set a variable to a value
config sgnum file params	config 1 chirpcw.cfg freq1=$freq1	calla config file
arb sgnum chan load arbnm clr seq filename	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
syncsec tmBefore	syncsec .9	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
waitsg tmBefore	waitsg .5	come back .5 secs before last startsg finishes
delay secs	delay 5.3	wait for 5.3 seconds
log "string"	log "start h3252"	send string to log file
terminp prompt	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 ascii.

Warning:

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 $parmName.

config sgnum file params

execute a config file.

set burstFreq "199.1"
set pulsew ".001"
set bcnt "199"
config sgNum burst1.cfg freq=$burstFreq,pulsew=$pulsew,bcnt=$bcnt

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 $parmName. eg:

SOURCE1:FREQ $freq
SOURCE1:FUNC:PULS:WIDTH $pulsew
SOURCE1:BURST:NCYCLES $bcnt

all lines in the config file will be:

read
parameters replaced with values
then sent to the specified generator.

All config files are currently relative to:/share/megs/phil/svn/aosoft/src/siggen/files

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 location.
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 sequence)
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 generator memory.
I've been using a sample clock of 50 usecs to 1 millisecond.

If you used a 100usec sample clock, the memory would fill up after 400 seconds. So longer sequences need slower clocks.

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 in generator

s stateNm repeatCnt playControl markerMode markerPos # comments

defines a seqment. takes advantage of the looping control built into the generator.
eg:

s arbstart 1 onceWaitTrig lowatstart 20 # low 10ms then wait for tick to start
s h70msi100ms 100 repeat highAtStartGoLow 400 # h70ms l20ms h.05ms l9.95

StateNm:

must already have been defined with: arb sgnum chn load command
limited to 12 chars.

repeatCnt:

how many times to repeat the state. Only used if playcontrol is repeat

playcontrol:

once : play once
onceWaitTrig : play once, then wait for trigger. used to sync with tick
repeat: repeat state using repeatCnt
repeatinf: repeat forever

markerMode

the marker is used to trigger a scope on a portion of a segment. It comes out on the sync bnc of the generator
Markermode tells how this output changes in the segment:

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

markerPos:

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 segments

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 the config
and you have to tell the generator to be in arb waveform mode.
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

home_~phil