Hello,
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?!
Regards,
Andy
Hi,
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.
New Generator Software verison 1.6.3 now also supports two extra options:
--off - Disable signal generation
--activate - Re-enable signal generation (only useful if it has been explicitly disabled previously)
New Generator Software version 1.6.4 now also support another option:
--select-device=<label> - select the device that matches the given label (e.g. serial) [Note: if no matching device is found the first device will be used]
Hello,
I tried this and it works provided you use (referring to the example given above) double inverted commas instead of single inverted commas.
Now the other thing is that it is painfully slow. Assuming you use the -- autoclose command (so that you can issue multiple remote commands) each command appears to force the software to execute the initialisation process, for example, reloading the factory calibration table. I tried to use the signal generator as an LO source in an automated mixer testing setup but I had to give up as I need to allow about 1 second (yes 1 second when the generator itself settles in about 300 us) before issuing a subsequent command. If you issue a second command before the first is complete then it is fatal. Additional instances of the application are launched that are unable to find the instrument and you end up having to reset your computer to close down all the unwanted Generator.exe processes. At one point I ended up with hundreds of Generator.exe processes which virtually ground the computer to a halt. Total chaos. In my case all I needed was to set frequency and level and switch the output put on and a simple DLL would have done the job.
