Contents:
C Call return value -> integer return code mapping
Query signal-hound’s physical state and hardware status.
| Returns: | dictionary containing current temperature, USB Voltage, and current: {
“temperature”: <Internal temperature of the SignalHound in Degrees Celcius.>,
“voltageUSB”: <USB operating voltage, in volts. Acceptable ranges are 4.40 to 5.25 V.>,
“currentUSB”: <USB current draw, in mA. Acceptable ranges are 800 - 1000 mA>,
}
|
|---|
The device temperature is updated in the API after each sweep is retrieved. The temperature is returned in Celsius and has a resolution of 1/8 th of a degree. A temperature above 70 ° C or below 0 ° C indicates your device is operating outside of its normal operating temperature, and may cause readings to be out of spec, and may damage the device.
A USB voltage of below 4.4V may cause readings to be out of spec. Check your cable for damage and USB connectors for damage or oxidation.
Will raise EnvironmentError for temperatures or voltages outside the allowable range.
Raw call BB_API bbStatus bbGetDeviceDiagnostics(int device, float *temperature, float *voltage1_8, float *voltage1_2, float *voltageUSB, float *currentUSB);
| Returns: | dictionary containing status information on the IQ data stream: {
“return_len”: <The number of IQ samples pairs which will be returned by calling bbFetchRaw().>,
“samples_per_sec”: <The number of IQ pairs to expect per second.>,
“bandwidth”: <The bandpass filter bandwidth, width in Hz. Width is specified by the 3dB rolloff points.>,
}
|
|---|
Use this function to characterize the IQ data stream.
Will raise IOError If the device is not open, not streaming, or if an unknown error is encountered..
Raw call BB_API bbStatus bbQueryStreamInfo(int device, int *return_len, double *bandwidth, int *samples_per_sec);
| Parameters: |
|
|---|---|
| Returns: | Nothing |
The verticalScale parameter will change the units of returned sweeps. If BB_LOG_SCALE is provided sweeps will be returned in amplitude unit dBm. If BB_LIN_SCALE is specified, the returned units will be in millivolts. If the full scale units are specified, no corrections are applied to the data and amplitudes are taken directly from the full scale input.
detectorType specifies how to produce the results of the signal processing for the final sweep. Depending on settings, potentially many overlapping FFTs will be performed on the input time domain data to retrieve a more consistent and accurate final result. When the results overlap detectorType chooses whether to average the results together, or maintain the minimum and maximum values. If averaging is chosen the min and max trace arrays returned from bbFetchTrace will contain the same averaged data
Will raise ValueError if invalid strings are passed (e.g. they’re not one of the specified values above).
Raw call: BB_API bbStatus bbConfigureAcquisition(int device, unsigned int detector, unsigned int scale);
| Parameters: |
|
|---|
This function configures the operating frequency band of the broadband device. Start and stop frequencies can be determined from the center and span.
The values provided are used by the device during initialization and a more precise start frequency is returned after initiation. Refer to the bbQueryTraceInfo function for more information.
Each device has a specified operational frequency range. These limits are BB#_MIN_FREQ and BB#_MAX_FREQ, where # is the signal-hound model number (see bb_api_h.py). The center and span provided cannot specify a sweep outside of this range. There is also an absolute minimum operating span.
Certain modes of operation have specific frequency range limits. Those mode dependent limits are tested against during initialization and not here.
Raises IOError on errors.
Raw call: BB_API bbStatus bbConfigureCenterSpan(int device, double center, double span);
| Parameters: |
|
|---|
When automatic gain is selected, the API uses the reference level provided to choose the best gain settings for an input signal with amplitude equal to reference level. If a gain other than BB_AUTO_GAIN is specified using bbConfigureGain, the reference level parameter is ignored.
The atten parameter controls the RF input attenuator, and is adjustable from 0 to 30 dB in 10 dB steps. The RF attenuator is the first gain control device in the front end.
When attenuation is automatic, the attenuation and gain for each band is selected independently. When attenuation is not automatic, a flat attenuation is set across the entire spectrum. A set attenuation may produce a non-flat noise floor.
Raises ValueError for invalid attenuation values, IOError for other errors.
Raw call: BB_API bbStatus bbConfigureLevel(int device, double ref, double atten);
| Parameters: | gain (float) – A gain setting |
|---|
To return the device to automatically choose the best gain setting, call this function with a gain of BB_AUTO_GAIN.
The gain choices for each device range from 0 to BB#_MAX_GAIN, where # is the signal-hound model number (see bb_api_h.py).
When BB_AUTO_GAIN is selected, the API uses the reference level provided in bbConfigureLevel to choose the best gain setting for an input signal with amplitude equal to the reference level provided.
After the RF input attenuator (0-30 dB), the RF path contains an additional amplifier stage after band filtering, which is selected for medium or high gain and bypassed for low or no gain.
Additionally, the IF has an amplifier which is bypassed only for a gain of zero.
For the highest gain settings, additional amplification in the ADC stage is used.
Raw call: BB_API bbStatus bbConfigureGain(int device, int gain);
| Parameters: |
|
|---|
The resolution bandwidth, or RBW, represents the bandwidth of spectral energy represented in each frequency bin. For example, with an RBW of 10 kHz, the amplitude value for each bin would represent the total energy from 5 kHz below to 5 kHz above the bin’s center. For standard bandwidths, the API uses the 3 dB points to define the RBW.
The video bandwidth, or VBW, is applied after the signal has been converted to frequency domain as power, voltage, or log units. It is implemented as a simple rectangular window, averaging the amplitude readings for each frequency bin over several overlapping FFTs. A signal whose amplitude is modulated at a much higher frequency than the VBW will be shown as an average, whereas amplitude modulation at a lower frequency will be shown as a minimum and maximum value.
Native RBWs represent the bandwidths from a single power-of-2 FFT using our sample rate of 80 MSPS and a high dynamic range window function. Each RBW is half of the previous. Using native RBWs can give you the lowest possible bandwidth for any given sweep time, and minimizes processing power. However, scalloping losses of up to 0.8 dB, occurring when a signal falls in between two bins, can cause problems for some types of measurements.
Non-native RBWs use the traditional 1-3-10 sequence. As of version 1.0.7, non-native bandwidths are not restricted to the 1-3-10 sequence but can be arbitrary. Programmatically, non-native RBW’s are achieved by creating variable sized bandwidth flattop windows.
sweepTime applies to regular sweep mode and real-time mode. If in sweep mode, sweepTime is the amount of time the device will spend collecting data before processing. Increasing this value is useful for capturing signals of interest or viewing a more consistent view of the spectrum. Increasing sweepTime has a very large impact on the amount of resources used by the API due to the increase of data needing to be stored and the amount of signal processing performed. For this reason, increasing sweepTime also decreases the rate at which you can acquire sweeps.
In real-time, sweepTime refers to how long data is accumulated before returning a sweep. Ensure you are capable of retrieving as many sweeps that will be produced by changing this value. For instance, changing sweepTime to 32ms in real-time mode will return approximately 31 sweeps per second (1000/32).
Rejection can be used to optimize certain aspects of the signal. Default is BB_NO_SPUR_REJECT, and should be used in most cases. If you have a steady CW or slowly changing signal, and need to minimize image and spurious responses from the device, use BB_SPUR_REJECT. If you have a signal between 300 MHz and 3 GHz, need the lowest possible phase noise, and do not need any image rejection, BB_BYPASS_RF can be used to rewire the front end for lowest phase noise.
Native Bandwidths (Hz) FFT size
10.10e6 16
5.050e6 32
2.525e6 64
1.262e6 128
631.2e3 256 Largest Real-Time RBW
315.6e3 512
157.1e3 1024
78.90e3 2048
39.45e3 4096
19.72e3 8192
9.863e3 16384
4.931e3 32768
2.465e3 65536 Smallest Real-Time RBW
1.232e3 131072
616.45 262144
308.22 524288
154.11 1048576
154.11 1048576
77.05 2097152
38.52 4194304
19.26 8388608
9.63 16777549
4.81 33554432
2.40 67108864
1.204 134217728
0.602 268435456
0.301 536870912
Raw Call: BB_API bbStatus bbConfigureSweepCoupling(int device, double rbw, double vbw, double sweepTime, unsigned int rbwType, unsigned int rejection);
| Parameters: |
|
|---|
Downsample factor settings:
Decimation-Rate Sample Rate (IQ pairs/s) Maximum Bandwidth
1 40 MS/s 27 MHz
2 20 MS/s 17.8 MHz
4 10 MS/s 8.0 MHz
8 5 MS/s 3.75 MHz
16 2.5 MS/s 2.0 MHz
32 1.25 MS/s 1.0 MHz
64 0.625 MS/s 0.5 MHz
128 0.3125 MS/s 0.125 MHz
This function is used to configure the digital IQ data stream. A decimation factor and filter bandwidth are able to be specified. The decimation rate divides the IQ sample rate directly while the bandwidth parameter further filters the digital stream.
For each given decimation rate, a maximum bandwidth value must be supplied to account for sufficient filter rolloff. That table is above. See bbFetchRaw() for polling the IQ data stream
Raw Call: BB_API bbStatus bbConfigureIQ(int device, int downsampleFactor, double bandwidth);
| Parameters: | window – The possible values for window are BB_NUTALL, BB_BLACKMAN, BB_HAMMING, and BB_FLAT_TOP. |
|---|
This changes the windowing function applied to the data before signal processing is performed. In real- time configuration the window parameter is permanently set to BB_NUTALL. The windows are only changeable when using the BB_NATIVE_RBW type in bbConfigureSweepCoupling. When using BB_NON_NATIVE_RBWs, a custom flattop window will be used.
Raw Call: BB_API bbStatus bbConfigureWindow(int device, unsigned int window);
| Parameters: | units – The possible values are BB_LOG, BB_VOLTAGE, BB_POWER, and BB_BYPASS. |
|---|
The units provided determines what unit type video processing occurs in. The chart below shows which unit types are used for each units selection. For “average power” measurements, BB_POWER should be selected. For cleaning up an amplitude modulated signal, BB_VOLTAGE would be a good choice. To emulate a traditional spectrum analyzer, select BB_LOG. To minimize processing power, select BB_BYPASS.
BB_LOG = dBm
BB_VOLTAGE = mV
BB_POWER = mW
BB_BYPASS = No video processing
Raw Call: BB_API bbStatus bbConfigureProcUnits(int device, unsigned int units);
| Parameters: |
|
|---|
Allows you to configure all zero-span trigger related variables. As with all configure routines, the changes made here are not reflected until the next initiate.
When a trigger is specified the sweep returned will start approximately 200 microseconds before the trigger event. This provide a slight view of occurances directly before the event. If no trigger event is found, the data returned at the end of the timeout period is returned.
Raw Call: BB_API bbStatus bbConfigureTrigger(int device, unsigned int type, unsigned int edge, double level, double timeout);
| Parameters: |
|
|---|
Time gates are relative to an external trigger.
Therefore it is necessary to use bbConfigureIO to setup an external trigger.
Raw Call: BB_API bbStatus bbConfigureTimeGate(int device, double delay, double length, double timeout);
Raw Call: BB_API bbStatus bbConfigureRawSweep(int device, int start, int ppf, int steps, int stepsize);
| Parameters: |
|
|---|
This function configures the device for both BB_RAW_SWEEP and BB_RAW_SWEEP_LOOP modes. This function allows you to configure the sweep start frequency, the number of 20 MHz steps to take across the spectrum, and how long to dwell at each frequency. There are restrictions on these settings, outlined below.
| Parameters: |
|
|---|
NOTE: This function can only be called when the device is idle (not operating in any mode). To ensure the device is idle, call bbAbort().
There are two configurable BNC connector ports available on the device. Both ports functionality are changed with this function. For both ports, ‘0’ is the default and can be supplied through this function to return the ports to their default values. Specifying a ‘0’ on port 1 returns the device to an internal time base and outputs the time base AC coupled. Specifying ‘0’ on port 2 emits a DC coupled logic low.
For external 10 MHz timebases, best phase noise is achieved by using a low jitter 3.3V CMOS input.
Configure combinations
Port 1 IO For port 1 only a coupled value must be ‘OR’ed together with a port type. Use the ‘|’ operator to combine a coupled type and a port type.
- BB_PORT1_AC_COUPLED Denotes an AC coupled port
- BB_PORT1_DC_COUPLED Denotes a DC coupled port
- BB_PORT1_INT_REF_OUT Output the internal 10 MHz timebase
- BB_PORT1_EXT_REF_IN Accept an external 10MHz time base
- BB_PORT1_OUT_LOGIC_LOW Self-explanitory
- BB_PORT1_OUT_LOGIC_HIGH Self-explanitory
Raw Call: BB_API bbStatus bbConfigureIO(int device, unsigned int port1, unsigned int port2);
| Parameters: |
|
|---|
This function can be called while the device is active. Note : If any of the boundary conditions are not met, this function will return with no error but the values will be clamped to its boundary values
Raw Call: BB_API bbStatus bbConfigureDemod(int device, int modulationType, double freq, float IFBW, float audioLowPassFreq, float audioHighPassFreq, float FMDeemphasis);
| Parameters: |
|
|---|
bbInitiate configures the device into a state determined by the mode parameter. For more information regarding operating states, refer to the Theory of Operation and Modes of Operation sections. This function calls bbAbort before attempting to reconfigure. It should be noted, if an error is returned, any past operating state will no longer be active.
Pay special attention to the bbInvalidParameterErr description below
Raw Call: BB_API bbStatus bbInitiate(int device, unsigned int mode, unsigned int flag);
| Returns: | dictionary containing the min and max arrays with eponymous keys. |
|---|
Returns a minimum and maximum array of values relating to the current mode of operation. If the detectorType provided in bbConfigureAcquisition is BB_AVERAGE, the arrays will contain identical values. Element zero of each array corresponds to the startFreq returned from bbQueryTraceInfo.
Raw Call: BB_API bbStatus bbFetchTrace(int device, int arraySize, double *min, double *max);
| Returns: | Numpy array of 4096 32-bit floating point values |
|---|
If the device is initiated and running in the audio demodulation mode, the function is a blocking call which returns the next 4096 audio samples. The approximate blocking time for this function is 128 ms if called again immediately after returning. There is no internal buffering of audio, meaning the audio will be overwritten if this function is not called in a timely fashion. The audio values are typically -1.0 to 1.0, representing full-scale audio. In FM mode, the audio values will scale with a change in IF bandwidth.
Raw Call: BB_API bbStatus bbFetchAudio(int device, float *audio);
| Returns: | dict containing:
- corrections 32-bit float array of length 2048. Correction values are decibel.
- index Index into the corrections array where the correction data begins.
- startFreq Frequency associated with the correction at index.
|
|---|
When this function returns successfully, the correction array will contain the frequency domain correction constants for the given bandwidth chosen. The corrections are modified based on temperature, gain, attenuation, and frequency. If any of these change, a new correction array should be requested. The correction array will only be generated again on a new bbInitiate(). The correction arrays and returned values differ slightly depending on the 7 or 20 MHz bandwidth chosen. Each one is described in depth below.
The correction array represents 40 MHz of bandwidth where frequencies outside the requested 20 MHz are zeroed out. The first non-zero sample begins at corrections[index]. The frequency at this index is startFreq. The bin size of each index is implied through 40 MHz divided by the length of the array, (40.0e6 / 2048) = 19531.25 Hz. If an Fourier transform is applied on the IF data, the correction values will line up with the usable 20 MHz bandwdith.
7MHz The correction array represents 10 Mhz of bandwdith where the usable 7 MHz is centered and all values outside the usable 7 MHz is zeroed. The index returned is the first non zero sample in the array. The startFreq returned is the frequency of the first sample in the array, corrections[0]. Every other sample’s frequency can be determined with the bin size. The bin size for this array is (10.0e6 / 2048) = 4882.8125 Hz. If a complex Fourier Transform is applied to the IQ data, the correction values will line up with the usable 7 MHz bandwidth.
##Tips
Time domain corrections of the signal’s amplitude require two steps. First, an inverse Fourier Transform must be performed on the entire correction array (including zero’ed portions). This results in a 4096 sample kernel. Second, the kernel is used in convolution with the time domain data. If a larger/smaller kernel is desired, interpolate/extrapolate the correction array while it is in the frequency domain to the desired length. Lengths which are powers of two are suggested.
Frequency domain correction of the signal’s amplitude requires you to first transform the raw data into the frequency domain. Performing an Fourier transform on the incoming data will yeild a frequency domain array that will align with the correction array. You can index the Transform results using the index returned from this function if you wish or apply the whole array. Remember that the corrections are in dB. If larger Transform sizes are desired, you can interpolate the correction array to the desired size. (Be aware! This will change the index of the first non-zero correction, but the results of the FFT will still align the with usable 20 MHz)
Raw Call: BB_API bbStatus bbFetchRawCorrections(int device, float *corrections, int *index, double *startFreq);
| Returns: | Numpy array of signed short integers |
|---|
This function is used to collect a single sweep for a device configured in raw sweep mode. The length of the buffer provided is determined by the settings used to configure the device for raw sweep mode. This length can be determined using the equation.
Buffer-Length = 18688 * ppf * steps
If the function returns successfully the array will contain a full sweep. The shorts will
Raw Call: BB_API bbStatus bbFetchRawSweep(int device, short *buffer);
| Parameters: | callbackFunc – Python function. Used as a callback to notify the user of completed sweeps. |
|---|
This function can be called after being configured and initiated in RAW_SWEEP_LOOP mode. The device begins sweeping on the first call to this function after the device has been initiated. It is possible to call this function multiple times per initiate to change the function call back used.
If this function returns successfully, the device begins sweeping immediately. The function provided is set as the callback function used when a sweep is completed. sweep_callback is called once per sweep completion. The function is passed two parameters, a pointer to the buffer of data for the sweep, and the length of the buffer, both ctypes variables: (bufPtr, bufLen).
To properly decode the passed parameters, you should use the SignalHound.decodeRawSweep staticmethod. This takes the two ctypes arguments in the order they are passed to the callback function, and returns a python numpy array.
The data buffer will not be overwritten when in the function body of sweep_callback. The API will maintain a circular list of buffers to store sweeps in. The API will store up to ¼ to ½ seconds worth of sweeps depending on parameters. If the function body of sweep_callback exceeds this amount of time, it is possible for the API to need to move ahead and skip over the buffer the user is still accessing. This will cause a loss of data. It is recommended the function body of sweep_callback is short, preferably simply copying the data from buffer into your own data structure. This ensures you receive every sweep and make your own decisions on when to drop/ignore sweeps.
The sweep_callback function is not called in the main thread of execution. It is called once per sweep, which can result in the function being called anywhere from 3-250 milliseconds. It is the responsibility of the user to not index the buffer out of range. The buffer contents can be modified by the user only during the function body of sweep_callback, once the function returns, the API is free to overwrite the contents. Modifying the contents of the buffer not in the function body of sweep_callback is undefined.
The user should not attempt to manage any of the memory provided through the buffer pointers.
The device sweeps indefinitely until bbAbort or bbCloseDevice is called. When operation is suspended via bbAbort, the device must be reconfigured and initiated again before calling this function.
Raw Call: BB_API bbStatus bbStartRawSweepLoop(int device, void(*sweep_callback)(short *buffer, int len));
| Returns: | dict containing:
“arr-size”: The size of arrays returned by bbFetchTrace.
“arr-bin-size”: The frequency difference between two
sequential bins in a returned sweep. In Zero-Span mode, binSize refers
to the difference between sequential samples in seconds.
“ret-start-freq”: The frequency of the first bin in a
returned sweep. In Zero-Span mode, start represents the exact center
frequency used by the API.
|
|---|
This function should be called to determine sweep characteristics after a device has been configured and initiated. For zero-span mode, startFreq and binSize will refer to the time domain values. In zero- span mode startFreq will always be zero, and binSize will be equal to sweepTime/traceSize.
Note: Calling while in BB_RAW_PIPE mode will produce a bbDeviceNotConfiguredErr
Raw Call: BB_API bbStatus bbQueryTraceInfo(int device, unsigned int *traceLen, double *binSize, double *start);
| Returns: | A Double containing the absolute center frequency of the streaming device. |
|---|
The function retrieves the center frequency of the 20 MHz IF bandwidth of a device currently initialized in raw pipe mode. The center returned is representative of ¼ of the IF sample rate. The 20 MHz of usable bandwidth is centered on this frequency.
Raw Call: BB_API bbStatus bbQueryStreamingCenter(int device, double *center);
| Returns: | Two-Tuple containing (in order):
seconds Integer Seconds since midnight (00:00:00), January 1, 1970, coordinated
universal time(UTC).
nanoseconds Integer nanoseconds between seconds and seconds + 1
|
|---|
This function is used in conjunction with bbSyncCPUtoGPS and a GPS device to retrieve an absolute time for a data packet in raw pipe mode. This function returns an absolute time for the last packet retrieved from bbFetchRaw. See the Appendix:Code Examples for information on how to setup and interpret the time information.
Raw Call: BB_API bbStatus bbQueryTimestamp(int device, unsigned int *seconds, unsigned int *nanoseconds);
Stops the device operation and places the device into an idle state.
Raw Call: BB_API bbStatus bbAbort(int device);
This function exists to invoke a hard reset of the device. This will function similarly to a power cycle(unplug/re-plug the device). This might be useful if the device has entered an undesirable or unrecoverable state. Often the device might become unrecoverable if a program closed unexpectedly, not allowing the device to close properly. This function might allow the software to perform the reset rather than ask the user perform a power cycle.
Viewing the traces returned is often the best way to determine if the device is operating normally. To utilize this function, the device must be open. Calling this function will trigger a reset which happens after 2 seconds. Within this time you must call bbCloseDevice to free any remaining resources and release the device serial number from the open device list. From the time of the bbPreset call, we suggest 3 to more seconds of wait time before attempting to re-open the device.
Raw Call: BB_API bbStatus bbPreset(int device);
This function causes the device to recalibrate itself to adjust for internal device temperature changes, generating an amplitude correction array as a function of IF frequency. This function will explicitly call bbAbort() to suspend all device operations before performing the calibration, and will return the device in an idle state and configured as if it was just opened. The state of the device should not be assumed, and should be fully reconfigured after a self-calibration.
Temperature changes of 2 degrees Celsius or more have been shown to measurably alter the shape/amplitude of the IF. We suggest using bbQueryDiagnostics to monitor the device’s temperature and perform self-calibrations when needed. Amplitude measurements are not guaranteed to be accurate otherwise, and large temperature changes (10 ° C or more) may result in adding a dB or more of error.
Because this is a streaming device, we have decided to leave the programmer in full control of when the device in calibrated. The device is calibrated once upon opening the device through bbOpenDevice and is the responsibility of the programmer after that.
Note: After calling this function, the device returns to the default state. Currently the API does not retain state prior to the calling of bbSelfCal(). Fully reconfiguring the device will be necessary.
Raw Call: BB_API bbStatus bbSelfCal(int device);
| Parameters: |
|
|---|
The connection to the COM port is only established for the duration of this function. It is closed when the function returns. Call this function once before using a GPS PPS signal to time-stamp RF data. The synchronization will remain valid until the CPU clock drifts more than ¼ second, typically several hours, and will re-synchronize continually while streaming data using a PPS trigger input.
This function calculates the offset between your CPU clock time and the GPS clock time to within a few milliseconds, and stores this value for time-stamping RF data using the GPS PPS trigger. This function ignores time zone, limiting the calculated offset to +/- 30 minutes. It was tested using an FTS 500 from Connor Winfield at 38.4 kbaud. It uses the “$GPRMC” string, so you must set up your GPS to output this string.
Raw Call: BB_API bbStatus bbSyncCPUtoGPS(int comPort, int baudRate);
| Returns: | Ascii string containing device type:
- “No device”
- “BB60A”
- “BB60C”
- “BB124”
|
|---|
This function may be called only after the device has been opened. If the device successfully opened, type will contain the model type of the device pointed to by handle.
Raw Call: BB_API bbStatus bbGetDeviceType(int device, int *type);
Returns: Device serial number as a integer.
This function may be called only after the device has been opened. The serial number returned should match the number on the case.
Raw Call: BB_API bbStatus bbGetSerialNumber(int device, unsigned int *sid);
Returns: Device firmware rev as a integer.
Use this function to determine which version of firmware is associated with the specified device.
Raw Call: BB_API bbStatus bbGetFirmwareVersion(int device, int *version);
Returns: Device API version as an ascii string.
The returned string is of the form major.minor.revision
Ascii periods (“.”) separate positive integers. Major/Minor/Revision are not gauranteed to be a single decimal digit. The string is null terminated. An example string is below ..
[ ‘1’ | ‘.’ | ‘2’ | ‘.’ | ‘1’ | ‘1’ | ‘\’ ] = “1.2.11”
Raw Call: BB_API const char* bbGetAPIVersion();
| Parameters: | errCode (integer) – Error code value |
|---|
Returns: Ascii string containing human-readable version of the error code.
Produce an ascii string representation of a given status code. Useful for debugging. Probably not really needed, since I’m doing error decoding locally in each function.
This /should/ be of type bbStatus. bbStatus is an enum with hard-coded values, so I’m being lazy, and just using an int. It works well enough.
Raw Call: BB_API const char* bbGetErrorString(bbStatus status);
Return a dictionary containing the return values from queryTraceInfo(), getDeviceDiagnostics() and the current acq_conf
If there is no running acquisition, queryTraceInfo() will be defaulted to {}
| Parameters: |
|
|---|
Decode a C array into a numpy-array using buffer casts. Assumes the values in the buffer are of datatype np.short
Assumed array size is sizeof(np.short) * buflen bytes, or effectively 2 * bufLen.
| Returns: | Numpy array containing contents of buffer |
|---|
Note: This function copies the data from the array, so it is valid even if the memory underlying the bufPtr is subsequently deallocated. This is intended for handling contexts like the callback, where once the callback returns, the SignalHound memory management may reuse or free the underlying buffer. Since the copied array will be managed by the python memory manager, it is safe to preserve beyond the scope of a calling function.
| Parameters: |
|
|---|
Decode a C array into a numpy-array using buffer casts.
Assumed array size is sizeof(dtype) * buflen bytes.
| Returns: | Numpy array containing contents of buffer |
|---|
Note: This function copies the data from the array, so it is valid even if the memory underlying the bufPtr is subsequently deallocated. This is intended for handling contexts like the callback, where once the callback returns, the SignalHound memory management may reuse or free the underlying buffer. Since the copied array will be managed by the python memory manager, it is safe to preserve beyond the scope of a calling function.