API for BPS4G?
I have recently purchased a BPS4G signal generator for an antenna network testing application. By having the signal generator attached to a remote PC and using remote desktop the generator can be controlled remotely (manually) using the generator application on the remote PC.
I'd like now to control this generator automatically from my own application to more fully automate the test cycle, and wondered the best way to get or construct an API for the generator. (I'm aware that the interface probably changes with device firmware as each update of the generator software comes with an associated firmware edition).
Is there an API that is (or can be made available) to control the generator?
If there is no API that can be made available, do you have any advice for me to construct my own? I can see the control string sent to the generator in debug mode within the software - should I just mirror those across a USB interface to the generator, or is it more complicated than that? Perhaps I should reverse-engineer from USB packets sent to the generator observed with a utility such as USB Device monitoring studio? Might I destroy the generator if I am not careful?!
Currently the way to control the generator automatically is to use commandline arguments of the control software. There are basically two variants for now:
--load-program=<program-name> - Here you can pass the name or filename of an already existing program that will be loaded and executed on the generator device.
--exec=<program-text> - Here you can pass a (new) program directly, using the same syntax as the software uses for stored programs except that newlines are replaced by semicolons. For example to write a sweep program that runs from 900 to 1000 MHz in 2 MHz steps for 5 seconds:
Generator.exe --exec='Program: Sweep; FrequencyStart: 900.0; FrequencyStop: 1000.0; FrequencyStep: 2.0; Duration: 5.0'
Note that you can have several such program steps in a single program, they will run in sequence then. Also a program will be repeated indefinitely by default.
Some other options that might be useful:
--no-show-status - Disables the automatic update of frequency and power value. The data transfers for those can sometimes interfere with the actual program execution causing jitter and other unwanted effects.
--autoclose - Close the application directly after writing the program. Without this option the UI will stay open.
Regarding writing a program, the following keywords are supported:
Program: <type> - What type of program is defined here, valid values are Sweep, CW, AM, FM and PM
Frequency: <freq> - Center/Carrier frequency to use in MHz, valid for CW, AM and PM
FrequencyStart: <freq> - Start frequency to use in MHz, valid for Sweep and FM (note: for FM this is actually the carrier frequency)
FrequencyStop: <freq> - Stop frequency to use in MHz, valid for Sweep and FM (note: for FM this defines the frequency deviation from FrequencyStart)
Power: <value> - Defines the power level in dBm, valid for CW, FM and PM
PowerStart: <value> - Defines the starting power level in dBm, valid for Sweep and AM
PowerStop: <value> - Defines the ending power level in dBm, valid for Sweep and AM
ModulationFrequency: <value> - Defines the modulation/pulse frequency in Hz, valid for AM, FM and PM
PulseLength: <time> - Defines the duration of one pulse in milliseconds, valid for PM
Duration: <time> - Defines the duration of one run of this program step in seconds, valid for Sweep, CW, AM, FM and PM. A value of zero for CW means indefinitely.
Passing values this way only performs minimal sanity checking, so it's possible to use values that won't work well together. Best to use the UI to create and test a program first.