Welcome to Akela AVMU’s documentation!

class avmu.AvmuInterface(share_from_interface=None)[source]

Create the base AVMU interface class.

This is the core class for acquiring data via an AKELA Inc. Vector Measurement Unit (or AVMU).

For multi-AVMU operation, pass the first created interface to any additional interface class instances. This allows all the interface instances to share the same underlying communication objects, which is needed for synchronized operation.

Note: If you don’t share the communcation object, calls such as broadcastBeginCommand() will not operate properly.

Unfortunately, there is no coherent way to validate this in the library code, so it’s left up to the user.

Accessing the same AVMU interface from separate threads is not threadsafe. However, Accessing different AVMU interface classes from separate threads that share the same underlying communication interface should be thread-safe.

Note: All library functions can theoretically raise Avmu_Exception_Bad_Handle if the internal task handle has been corrupted. As such, this particular exception will not be explicitly enumerated for every possible call.

addPathToMeasure(tx_path, rx_path, who_is_transmitting=None, port_is_transmitting=None)[source]

Add a path to measure.

Adds a path to the list of active paths that will be measured when data is actually acquired.

Parameters:
  • tx_path (str) – Transmitting port of the path to add. Note that this can very well be TX_NONE, if your application is using multiple AVMUs, and one of the other AVMUs is the one actively transmitting.
  • rx_path (str) – RX Path for the combo. This can be RX_NONE if there is no need for the associated rx data. Note that RX_NONE will still return data (as the transmitter will still need to do the associated frequency stepping), but the return content will be only cross-board leakage within the AVMU.
Returns:

Nothing

Raises:

Avmu_Exception_Bad_Path – if a path value specified is invalid.

clearMeasuredPaths()[source]

Clear list of paths being measured.

Returns:Nothing
getFrequencies()[source]

Get a list containing the actual frequencies the hardware will sample for the configured sweep in task t. Units are MHz.

The actual frequency points can differ from the requested frequency points because the hardware has fixed precision, and cannot achieve every arbitrary frequency value within its tunable bands. The values in this list are the requested frequency points after snapping them to the closest achievable frequency.

Returns:list of floating point frequencies, in MHz
setFrequencies(freqs)[source]

Set the frequencies to measure during each sweep. Units are MHz.

Note that the AVMU frequency generation hardware has fixed precision and so the generated frequency may not be exactly equal to the requested frequency. This function silently converts all requested frequencies to frequencies that can be exactly generated by the hardware. This has important implications for Doppler noise when doing a linear sweep. AKELA recommends using the function utilFixLinearSweepLimits() to ensure every frequency is exactly generateable and that the frequencies are equally spaced. Use the getFrequencies() function to get the actual frequencies being generated.

Parameters:

freqs (list) – array of frequencies to sample, in MHz

Returns:

Nothing

Raises:
getHopRate()[source]

Get the frequency hopping rate associated with this Task object. If no rate has yet been set, this function returns HOP_UNDEFINED.

Returns:Current hop rate as a string.
setHopRate(hop_str)[source]

Set the frequency hopping rate. See the values defined in the “HopRate” type above.

Parameters:

hop_str (str) – The new hop rate.

Returns:

Nothing

Raises:
getIPAddress()[source]

Get the current AVMU IP address for the Task object. When no IP has yet been set, this will return a NULL char*.

Returns:string of the current remote IP. If the IP is unset, returns None
setIPAddress(ip_address)[source]

Sets the IPv4 address of the unit to communicate with. The ipv4 parameter is copied into the Task’s memory. On success the Task’s state will be TASK_UNINITIALIZED. :param ip_address: :type ip_address: str

Raises:Avmu_Exception_Wrong_State`if the Task is not in the ``TASK_UNINITIALIZED` or TASK_STOPPED state
getIPPort()[source]

Get the current port for IP communications. When uninitialized, this will default to 0.

setIPPort(port)[source]
Sets the port on which to communicate with the unit.

The value of port MUST be > 1024, as 1024 is reserved for broadcast operations.

Note that for multi-unit configurations, each unit must be assigned a unique port > 1024 (the AVMU units listen on all ports, but only respond to broadcast commands on port 1024). On success, the Task’s state will be TASK_UNINITIALIZED.

Parameters:port (int) –
Raises:Avmu_Exception_Wrong_State`if the Task is not in the ``TASK_UNINITIALIZED` or TASK_STOPPED state
getMeasurementType()[source]

Get the current measurement ProgramType type.

Returns:(str) Current measurement type.
setMeasurementType(measure_type)[source]

Set the measurement type (synchronous or asynchronous). Note that the AVMU defaults to synchonous (PROG_SYNC).

Parameters:measure_type (str) One of the ProgramType types (PROG_ASYNC or PROG_SYNC) –
setGainSetting(gain_setting)[source]

Control IF gain.

The AVMU has the facility for configurable gain within the IF stage of the RF pipeline.

Parameters:gain_setting (str) A value in the IfGain Enum (e.g. "AVMU_GAIN_*") –
Raises:Avmu_Exception_Wrong_State if the task is either UNINITIALIZED or STOPPED.
getGainSetting()[source]

Get the current IF gain setting.

Returns:(str) Current IF gain settings.
setReceiver12dBPad(insert_pad)[source]

Control whether an optional 12dB pad is inserted in the internal RF chain.

Parameters:insert_pad (bool) – Whether the pad is inserted.
getReceiver12dBPad()[source]

TODO: Untested!

Get whether the optional 12DB pad is inserted into the RF chain.

Returns:(bool) True if pad is enabled.
getNumberOfFrequencies()[source]

Get the number of frequency points for the sweep configured for the Task. If no frequencies have been set, this function returns 0.

Returns:(int) Number of frequency points in the current sweep.
utilGenerateLinearSweep(startF_mhz, stopF_mhz, points)[source]

Generates a linear sweep with the requested parameters. Note that the start and end frequency will be adjusted as documented in utilFixLinearSweepLimits() so that all frequency points fall on exactly generateable values. This function internally calls setFrequencies() with the resulting array. The caller can retrieve the frequency list with the getFrequencies() function. Since it changes the frequencies this function is only available in the TASK_STOPPED state.

If startFreq == endFreq, the hardware will effectively be placed in zero-span mode, as it will repeatedly sample the same frequency for the duration of the sweep. This is a valid operating mode.

Parameters:
Raises:
getTimeout()[source]

Get the current UDP socket transport timeout.

Returns:(int) socket timeout, in milliseconds.
setTimeout(timeout_ms)[source]

Sets the default time to wait, in milliseconds, for a unit to reply to a command before giving up and returning an ERR_NO_RESPONSE condition. For the measurement functions, this is the amount of time to wait beyond the expected sweep time. When a Task is created, the timeout value defaults to 100.

A timeout value of 0 results in non-blocking call, where the call will return immediately if there is no data in the OS receive buffer.

Parameters:timeout_ms (int) –
Returns:Nothing
isSerialPortPresent()[source]

Get whether the remote hardware has a serial port peripheral.

Returns:True if the hardware supports a serial port, False if not.
setSerialPortFeature(enable, buffer_size=128)[source]

If the remote hardware has a serial port, this call configures it.

Parameters:
  • enable (bool) –
  • buffer_size (int) –
Raises:

Avmu_Exception_Feature_Not_Present – if the remote AVMU does not have a serial port.

isShaftEncoderPresent()[source]

Get whether the AVMU has support for external shaft encoder inputs.

Returns:(bool) whether the connected AVMU has support for encoders
setShaftEncoderFeature(enable, resetOnStart=True)[source]

If the AVMU supports encoders, this allows you to enable the encoders, and optionally reset the cumulative encoder counter.

Parameters:
  • enable (bool) –
  • resetOnStart (bool) –
Raises:

Avmu_Exception_Feature_Not_Present – if the remote AVMU does not have encoder support.

configureTddSettings(tddActive=False, tddEnabled=False, nullingEnabled=False, powerAmpState=False, slave=False, attenuatorEnabled=False, lnaEnabled=False, attenuatorValue=0, tx=0, tx_to_rx1=0, rx1=0, rx1_to_rx2=0, rx2=0, rx2_to_tx=0)[source]
getState()[source]
Get the current state of the Task.
Returns:(str) One of ‘TASK_RUNNING’, ‘TASK_STARTED’, ‘TASK_STOPPED’ or ‘TASK_UNINITIALIZED’.
getHardwareDetails()[source]

Get the hardware details for the unit associated with this AvmuInterface instance.

TODO: VALIDATE THIS!

Parameters:None
Returns:A dictionary of the HardwareDetails members -> value mappings. If the Task has not yet been initialized, the returned dict has all values set to 0.
utilPingUnit(tries=5)[source]

Sends an “are you there” message to the unit.

Note that this function should not be called while a frequency sweep is ongoing, because it causes that sweep to prematurely halt and respond to this message instead. This is only an issue in multithreaded code or when in async mode, as the sync data acquisition functions are blocking. This function waits for a reply for the length of time specified by getTimeout() before giving up.

Note that this can be called from any state, provided an IP and port are present.

Raises an exception if the unit did not respond, returns nothing otherwise.

Parameters:

tries (int) – The call will block for at most tries * timeout milliseconds. Note that certain states can cause the hardware to be unable to respond to the first ping, so tries > 1 is generally recommended.

Raises:
versionString()[source]

Returns a string describing the version of the DLL and its components.

Returns:String describing the AVMU DLL components and version numbers.
utilFixLinearSweepLimits(startF, endF, npts)[source]

Adjusts the start and end of a requested linear sweep with N points such that all frequencies in the sweep will land on exactly generateable values, and the inter-point spacing is constant across the entire scan. Unequal spacing will cause Doppler noise in the data.

This may move the start and end frequencies of the scan slightly (<1 MHz).

If the input frequencies are equal, or N is 1, the frequencies are each simply adjusted to exactly generateable values.

TODO: VALIDATE THIS!

Parameters:
Returns:

Adjusted start and stop frequencies as a 2-tuple

Raises:
utilNearestLegalFreq(freq)[source]

Adjusts a requested frequency, in MHz, to the nearest able to be generated by the hardware. This is not available in the TASK_UNINITIALIZED state, as it requires knowledge of the hardware not read from the AVMU until initialized.

Parameters:target_freq (float) –
Returns:Adjusted target_freq Frequency value as a float
Avmu_Exception_Wrong_State if the Task is not in the TASK_STOPPED state Avmu_Exception_Freq_Out_Of_Bounds if a frequency is beyond the allowed min/max. (You can get the min and max from the HardwareDetails struct returned by getHardwareDetails())
initialize()[source]

Attempts to talk to the unit specified by the Task’s IP address and port, and download its details. If it succeeds the Task enters the TASK_STOPPED state.

Raises:
beginAsync()[source]

Begin async data collection. This call emits the trigger message that will cause the remote hardware to immediately begin acquiring frequency data continuously.

Note that once beginAsync() has been called, you MUST then call measure() periodically so that the UDP recieve buffer will not overflow.

broadcastBeginCommand(handles=[])[source]

Broadcast a “begin” command to all avmus on the local network. This will start the sweep of every avmu on the network at the current position of its internal PC, and therefore depends on the avmus having been preconfigured to the proper start addresses using beginAsync().

Parameters:

handles (list of AvmuInterface) –

Raises:
haltAsync()[source]

This causes an immediate halt of the async sweep acquisition in the remote hardware.

Any pending data in the UDP recieve buffer will be flushed, and the hardware will be returned to the “started” state.

To resume async data collection after calling haltAsync(), simply call beginAsync().

interruptMeasurement()[source]

Interrupts one of the measurement functions while it is waiting for data.

Since the measurement functions are blocking in SYNC mode, this function must be called from a different thread. This function returns immediately, however the measurement function may continue to block for a short additional amount of time.

Raises:Avmu_Exception_Wrong_State if the Task is not in the TASK_STARTED state
start()[source]

Attempts to program the AVMU using the settings stored in the Task object. If it succeeds the Task enters the TASK_STARTED state.

Raises:
stop()[source]
Puts the Task object into the TASK_STOPPED state.
Raises:Avmu_Exception_Wrong_State if the Task is not in the TASK_STARTED state
measure()[source]

Take a measurement.

In PROG_SYNC mode, this triggers a measurement, and blocks until its response has been fully received and decoded.

This function does various things depending on the sweep trigger type and the program type. Sync mode, internal trigger: run avmu program, block until data is received or timeout Sync mode, external trigger: block until data is received or timeout Async mode, internal trigger: block until 1 program’s worth of data is received or timeout Async mode, external trigger: block until 1 program’s worth of data is received or timeout

Note that beginAsync() must be called prior to measure() in async mode. The pattern is beginAsync(), measure(), measure(), measure(), …, haltAsync()

If the AvmuTask is in async mode (setMeasurementType called with PROG_ASYNC) this simply serves to consume any UDP messages generated by the hardware. Note that since the hardware asynchronously emits data continuously, you therefore must call this periodically, or you risk overrunning the socket receive buffer.

Typically, overrunning the buffer will result in a Avmu_Exception_Bytes return code, but it’s theoretically possible to have an entire sweep be dropped (either if it fits in a single packet, or if all the packets for the sweep get dropped).

In this case, the only indicator of data loss will be a non-monotonic sweep number in the returned data.

In general, it’s probably ideal to just continualy call this.

In both cases, measure() places the acquired data in the RX queue, ready to be extracted by calling extractSweepData().

Raises:

Rare Avmu_Exception_Bytes, particularly when not on a dedicated subnet are not entirely unknown, but they shouldn’t happen frequently.

If you encounter large numbers of Avmu_Exception_Bytes returns, there can be a number of causes. TCP Checksum offloading has been known to cause this, as could not calling measure() frequently enough. Lastly, check the intervening network hardware. You might have a failing switch/hub.

Note that the AVMU hardware is particularly intolerant of network hubs, as its UDP transport does not support data retransmits. Any collisions will result in a corrupted sweep (but really, it’s 2018+, why are you running a network hub?).

getnumberOfEnabledReceivers()[source]

Returns the number of receivers in the AVMU.

getEnabledReceivers()[source]

Returns a list describing which of the AVMU’s receivers will return data.

setEnabledReceivers(enable_list)[source]

Configure which of the receivers in the AVMU will return data.

extractSweepData(tx_path, rx_path)[source]

Extract the sweep data for a given path described by a TX port and RX port.

Note that this interface has the limitation that it does not support multiple measurements of the same path within the overall AVMU acqusision frame.

Parameters:
  • tx_path (str) – TX port of the path to extract.
  • rx_path (str) – RX port of the path to extract.
Returns:

  • A 2-tuple of containing (data, metadata)
    data is a numpy complex array with the dimensions of 1 x getNumberOfFrequencies(),
    where each value bin corresponds to the associated frequency bin in getFrequencies().
    metadata is a dict containing the sweep metadata associated with the sweep data.
    It contains the following key-> value pairs:
    • tx_port - Transmitting port, as a integer.
    • tx_port_s - Transmitting port, as a string compatible with addPathToMeasure().
    • rx_port - Receiving port, as a integer.
    • rx_port_s - Receiving port, as a string compatible with addPathToMeasure().
    • timestamp_ticks Currently unused. Read as zero.
    • timestamp_seconds Currently unused. Read as zero.
    • sweep_number Monotonically increasing counter of the number of sweeps (note:
      sweeps, not frames)
    • shaft_encoder_left Shaft encoder accumulator for the left-hand shaft encoder.
      If not enabled, will return 0.
    • shaft_encoder_right Shaft encoder accumulator for the right-hand shaft encoder.
      If not enabled, will return 0.
    • serial_data_age Age of the serial port data. If serial is not enabled, will return 0.
    • serial_data_bytes Serial data itself, as a bytes array. If not enabled, will be an empty bytes object.

Raises:

Avmu_Exception_Bad_Path – if a path value specified is invalid.

extractAllPaths()[source]

Given a set of measured paths that are unique, extract every path and return them as a list.

This call presumes the user has called measure() prior to it’s invocation. If not, it will raise Avmu_Exception_Path_Has_No_Data: if you didn’t call measure()

Returns:A list of 2-tuples (path_info, data).

path_info is a dict containing the following:

  • who_is_transmitting Which unit is doing the transmitting. This is only relevant in a multi-AVMU context. Single-AVMU setups can ignore it.
  • port_is_transmitting Which port on the transmitting unit is active. This is only relevant in a multi-AVMU context. Single-AVMU setups can ignore it.
  • tx_path Which port on the current AVMU is transmitting. For multi AVMU configurations, when the current AVMU is not transmitting, this will be TX_NONE.
  • rx_path Which port on the current AVMU is receiving.
  • receiver_chan Which receiver is the dataset for. At the moment, this is ALWAYS 0, as no multi-receiver AVMUs are available.

In the general single-unit case, you can ignore all the keys other then tx_path and rx_path.

data is a dict containing two keys:

  • data The actual sweep’s data. This is directly the data return component from the extractSweepData() call.
  • meta The sweep’s metadata. This is directly the metadata return component from the extractSweepData() call.
Raises:Avmu_Exception_Path_Has_No_Data – if you didn’t call measure()
setSyncPulseMode(sync_mode)[source]

Configure the inter-AVMU synchronization pulse mode for the specified AVMU.

The SyncPulseMode is used to allow coordinated acquisition between multiple AVMUs. In coordinated operation, the master unit is set to SYNC_GENERATE, and any slave units are set to SYNC_RECEIVE. This causes the master to emit sweep start outputs, which are consumed by the slave units.

Note that this requires specialized hardware support, and dedicated syncronization wiring.

Additionally, to properly synchronize, all units must receive their start command within 1 ms of each other, which is accomplished via the broadcastBeginCommand() call. This also requires the shared-communication-infrasturcture provided by the createSharedTask() call. All AVMU tasks used in a coordinated acqusition must share their internal communication object.

Parameters:sync_mode (str) –
Raises:Avmu_Exception_Wrong_State`if the Task is not in the ``TASK_UNINITIALIZED` or TASK_STOPPED state
getSyncPulseMode()[source]

Get the current sync pulse mode for this unit.

Returns:Current sync-pulse mode as a string.
addExclusionBand(start_freq, stop_freq)[source]

Exclusion bands are used to prevent the AVMU from transmitting in specific frequency ranges. This is generally used to “mask out” sensitive RF regions, so things like GPS are not negatively affected by the AVMU.

The AVMU will still take data at points within the exclusion band, but the RF output will be disabled.

Multiple exclusion bands are logically ORed together. Basically, if a frequency point falls within any exclusion band, it will result in the RF output being disabled.

As such, repeated or overlapping exclusion bands are valid (though they are somewhat pointless).

Note that you cannot add exclusion bands before connecting to an AVMU.

Note that start_freq must be smaller then stop_freq.

Parameters:
  • start_freq (float, MHz) –
  • stop_freq (float, MHz) - End of the exclusion band (MUST be larger then start_freq) –
Raises:

Avmu_Exception_Wrong_State if the Task is not in the TASK_STOPPED state

clearExclusionBands()[source]

Clear the internal list of exclusion bands stored in the AvmuInterface.

Raises:
getExclusionBandCount()[source]

Get the number of separate exclusion bands configured in the AvmuInterface.

This is required to enumerate the active exclusion bands.

Returns:exclusion_band_count(int) number of exclusion bands configured.
Raises:Avmu_Exception_Wrong_State if the Task is not in the TASK_STOPPED state
getExclusionBand(band_idx)[source]

Get the (start_f_mhz, stop_f_mhz) values for exclusion band band_idx.

Given a index of 0 <= idx < getExclusionBandCount(), return the corresponding exclusion band start/end frequency.

Returns:

2-tuple of start_f_mhz (double), stop_f_mhz (double)

Raises:
getPreciseTimePerFrame()[source]

Get the precise time (in seconds) that a Frame will take.

This function only operates properly when a AVMU is in the started or running states, as the sweep program is not computed until the transition to the started state.

Returns:
Frame time, as a double, in fractional seconds.
If the task is not valid, or in the correct state, the return value is -1.

Exceptions

Each exception corresponds to the eponymous C error return code, prefixed with Avmu_Exception_.

Note that these exceptions are also available as avmu.Avmu_Exception_*, as they’re star-imported into the main avmu module.

exception avmu.avmu_exceptions.Avmu_Exception[source]

Bases: Exception

Base exception class that all library exceptions inherit from. This can be used to easily catch all exceptions that are specifically thrown by the avmu library.

exception avmu.avmu_exceptions.Avmu_Exception_Bad_Atten[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

Error code indicating the specified attenuation value was not valid.

exception avmu.avmu_exceptions.Avmu_Exception_Bad_Cal[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

Error code indicating the current calibration is invalid. Only relevant for VNAs.

exception avmu.avmu_exceptions.Avmu_Exception_Bad_Handle[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

Error code indicating the current handle passed to a DLL function was not valid.

Generally indicates an internal error. If this occurs repeatedly, please contact support.

exception avmu.avmu_exceptions.Avmu_Exception_Bad_Hop[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

Error code indicating the specified hop-rate value was not valid.

exception avmu.avmu_exceptions.Avmu_Exception_Bad_Path[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

Error code indicating the specified path is not allowed, or was invalid.

exception avmu.avmu_exceptions.Avmu_Exception_Bad_Prom[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

Error code indicating that the AVMU PROM was not in a known format. Please contact support if this is a reoccurring issue.

exception avmu.avmu_exceptions.Avmu_Exception_Bytes[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

Error code indicating the DLL has received an incorrect number of bytes from the AVMU. Possibly indicative of a network issue.

exception avmu.avmu_exceptions.Avmu_Exception_Freq_Out_Of_Bounds[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

Error code indicating one of the specified frequency bounds was beyond the hardware’s available range.

exception avmu.avmu_exceptions.Avmu_Exception_Interrupted[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

Error code indicating that the measurement was asynchronously interrupted from another thread.

exception avmu.avmu_exceptions.Avmu_Exception_No_Response[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

Error code indicating the remote instrument failed to respond to commands within the current timeout period. If this persists, check your network and try power cycling the AVMU.

exception avmu.avmu_exceptions.Avmu_Exception_Missing_Ip[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

Error code indicating you have not yet specified the IP of the remote device before connecting.

exception avmu.avmu_exceptions.Avmu_Exception_Missing_Port[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

Error code indicating you have not yet specified the port for the remote device before connecting.

exception avmu.avmu_exceptions.Avmu_Exception_Missing_Hop[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

Error code indicating you have not yet specified the hop-rate for the remote device before connecting.

exception avmu.avmu_exceptions.Avmu_Exception_Missing_Atten[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

The switchboard config requires an attenuation value to be specified, and it has not been.

exception avmu.avmu_exceptions.Avmu_Exception_Missing_Freqs[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

Error code indicating you have not yet specified the frequency endpoints for the remote device before connecting.

exception avmu.avmu_exceptions.Avmu_Exception_Prog_Overflow[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

Error code indicating the generated program to run on the remote device was larger than it can handle.

exception avmu.avmu_exceptions.Avmu_Exception_Socket[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

Error code indicating an unknown socket error occured.

exception avmu.avmu_exceptions.Avmu_Exception_Too_Many_Points[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

Error code indicating you are trying to take more data points than the hardware is capable of.

exception avmu.avmu_exceptions.Avmu_Exception_Wrong_State[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

Error code indicating the hardware is not in the correct state for the function you are trying to call.

exception avmu.avmu_exceptions.Avmu_Exception_Empty_Prom[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

Error code indicating the remote device’s PROM appears to be empty. Power cycle the AVMU, and if the problem persists, contact Akela.

exception avmu.avmu_exceptions.Avmu_Exception_Path_Already_Measured[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

Error code indicating you are adding a path to measure that you had already added.

These restrictions have been relaxed in recent releases.

exception avmu.avmu_exceptions.Avmu_Exception_No_Measured_Paths[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

Error code indicating there are no paths to measure, and the hardware has nothing to do.

exception avmu.avmu_exceptions.Avmu_Exception_Wrong_Program_Type[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

Error code indicating you are in sync mode and are trying to call an async startup function.

exception avmu.avmu_exceptions.Avmu_Exception_Unknown_Feature[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

Error code indicating the AVMU’s prom indicates it has a hardware feature that this version of the DLL doesn’t know about. Either indicates you need to update, or the prom is corrupted.

exception avmu.avmu_exceptions.Avmu_Exception_Feature_Not_Present[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

You are trying to configure a hardware feature not present in the connected AVMU.

exception avmu.avmu_exceptions.Avmu_Exception_No_Attenuator_Present[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

You are trying to specify an attenuation value on hardware without an attenuator.

exception avmu.avmu_exceptions.Avmu_Exception_Bad_IP_Port[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

The UDP port you specified is not valid. You must use a port >= 1024 and < 65535

exception avmu.avmu_exceptions.Avmu_Exception_Task_Array_Invalid[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

The batch-task array parameter appears to not be valid.

exception avmu.avmu_exceptions.Avmu_Exception_Path_Has_No_Data[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

No data was acquired for the specified path. Either you didn’t add the path, didn’t call measure(), or something else is wrong.

exception avmu.avmu_exceptions.Avmu_Exception_Err_Index_Out_Of_Bounds[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

The sweep index/exclusion band you are trying to extract is outside the bounds of the array.

exception avmu.avmu_exceptions.Avmu_Exception_Err_Invalid_Parameter[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

One of the specified parameters is not valid. If you are specifying sweep frequency, check your frequency bands.

exception avmu.avmu_exceptions.Avmu_Exception_Err_Prom_Invalid_Feature_Configuration[source]

Bases: avmu.avmu_exceptions.Avmu_Exception

The AVMU’s prom contains feature flags that are incompatible with each other.
Please contact support.

Constants

API Constants. These are primarily passed to various arguments as literal strings.

Settings for the hop-rate (e.g. time spent sampling each frequency point) in a sweep.
Faster hop rates result in lower dynamic range (but faster sweeps).
  • HOP_UNDEFINED - Hop rate not set yet
  • HOP_90K - This rate is currently unsupported but may be enabled in the future 90K Pts/second
  • HOP_45K - Hop rate of 45K points/second
  • HOP_30K - Hop rate of 30K points/second
  • HOP_15K - Hop rate of 15K points/second
  • HOP_7K - Hop rate of 7K points/second
  • HOP_3K - Hop rate of 3K points/second
  • HOP_2K - Hop rate of 2K points/second
  • HOP_1K - Hop rate of 1K points/second
  • HOP_550 - Hop rate of 550 points/second
  • HOP_312 - Hop rate of 312 points/second
  • HOP_156 - Hop rate of 156 points/second
  • HOP_78 - Hop rate of 78 points/second
  • HOP_39 - Hop rate of 39 points/second
  • HOP_20 - Hop rate of 20 points/second

Available task states.

  • TASK_UNINITIALIZED - Task state of uninitialized
  • TASK_STOPPED - Task state of stopped
  • TASK_STARTED - Task state of started
  • TASK_RUNNING - Task state of running

Acquisition mode (synchronous, asynchronous) for the current acquisition

  • PROG_ASYNC - Asynchronous acquisition mode
  • PROG_SYNC - Synchronous acquisition mode

Indices and tables