Skip to content
/ avmu Public

Interface to AKELA Inc's Vector Measurement Units.

Notifications You must be signed in to change notification settings

AkelaInc/avmu

Repository files navigation

AVMU Interface

Python 3 interface to AKELA Inc's vector meaurement units.

Complete API Documentation here

Quickstart:

import avmu

AVMU_IP_ADDRESS = "192.168.1.219"
HOP_RATE        = "HOP_15K"
START_F         = 250
STOP_F          = 2100
NUM_POINTS      = 1024
SWEEP_COUNT     = 100

device = avmu.AvmuInterface()
device.setIPAddress(AVMU_IP_ADDRESS)
device.setIPPort(1027)
device.setTimeout(500)
device.setMeasurementType("PROG_ASYNC")

device.initialize()

device.setHopRate(HOP_RATE)
device.addPathToMeasure('AVMU_TX_PATH_0', 'AVMU_RX_PATH_1')

device.utilGenerateLinearSweep(startF_mhz=START_F, stopF_mhz=STOP_F, points=NUM_POINTS)

# Get the freqency plan that utilGenerateLinearSweep calculated given the
# hardware constraints.
frequencies = device.getFrequencies()

# Arm the device
device.start()

sweeps = []

# Tell the AVMU to start asynchronous acquisitions.
device.beginAsync()

# Consume asynchronously generated frequency sweeps
for _ in range(count):

    device.measure()
    sweep_data = device.extractAllPaths()
    sweeps.append(sweep_data)
    print("Acquired sweep (%s)" % (len(sweeps), ))

# Stop the asynchronous acquisition
device.haltAsync()

# Finally, disarm the acquisition.
device.stop()

Significantly more comprehensive examples are included in demo-simple.py and demo-threaded.py.

  • demo-simple.py shows how to properly convert acquired frequency domain data into time-domain data, for extracting meaningful range profiles. It also includes a waterfall plot for viewing motion the returned data, if desired.
  • demo-threaded.py implements a much more robust, error tolerant client for the AVMU, with proper handling for the various way the network connection can hiccup.

Usage:

If you clone this repository, the examples can be run directly, as the avmu package is present in the repository as well. However, for external projects, this depends on you manually placing the avmu directory in the root of any project that would like to use it.

Alternatively, avmu is also available in PyPi, so pip install avmu will make the avmu interface package available globally. At that point, either of the example files can be run from any location.

Changes:

0.1.1

  • The configureTddSettings() call's signature has changed slightly. It now takes two different enable parameters. tddActive controls whether the TDD parameters get written to the TDD board at all, whereas tddEnabled controls whether the TDD board enable bit is set within the parameters written when tddActive is set to true. 0.1.0
  • Breaking change: Preliminary support for new multiple-receiver hardware. This has resulted in changes to the structure returned by extractAllPaths() to allow multiple datasets for a single measured path (as multiple receivers allow simultaneous reception from multiple inputs). As a result, the data member returned by extractAllPaths() is now a dict of rx_num -> np-array values in all cases (even for single receiver usage). This should only require a simple addition of one additional member[0] access for existing code, but it is a breaking change.
  • Possible breaking change: getHardwareDetails() now returns switchboard type as a string, rather then a integer. This was changed principally because the int value corresponded to a undocumented enum value, and that was difficult to use.
  • Certain error states in the native-code layer will no longer throw a uncaught C++ exception, but will now correctly return a ERR_FEATURE_NOT_PRESENT error code. Sorry about that!
  • Windows/Linux builds removed as I don't have the build infrastructure at the moment (Akela closed!) Complain on github if this is a problem, I can probably lash something up at home.

0.0.12

  • Remove setup.py windows check (thanks #1!)

0.0.11

  • Add extra setup classifiers that indicate MacOS/Linux support (whoops!)

0.0.10

  • This changeset primarily adds (preliminary) support for MacOS. There are no internal changes to the AVMU library, it solely consists of adding support for locating/loading MacOS DyLibs, and the associated (internal) build-process support for compiling on MacOS. Additionally, the windows build environment was also updated to VC141 (VS2017). This should not affect users of this library, as the C ABI is stable across versions.

0.0.9

  • The combo utils tool has been updated to include the transmitting AVMU in each combo tuple. This will require any software that uses avmu.combo_utils to be updated, but as that particular file is so-far undocumented, this is not regarded as a breaking change. This change is motivated entirely by internal use of the library.

0.0.8

  • Added linux x86_64 shared object. This .so was built on ubuntu 16.04, so it will likely work on most debian variants.

0.0.7

  • Minor DLL lookup improvements. Added linux armv7l shared object (e.g. raspberry pi version).

0.0.6

  • Re-enable RTTI in the DLL, so it stops exploding. Whoops, sorry about that.

0.0.5

  • utilPingUnit() now takes an optional parameter to specify the number of retry attemps for the ping.
  • Default timeout library-wide set to 100 milliseconds. Previously, it was 1000 milliseconds (and mis-documented as being 150). 1000 ms doesn't make much sense in the context of the hardware, which cannot (generally) perform blocking operations at all. As such, it can't take longer then a millisecond or two to respond, if it received a message at all.

0.0.4:

  • Improved return of getHardwareDetails() call to include hardware feature flags,
    which makes determining what a remote AVMU can do easier then just trying to
    turn on assorted features and seeing if you get errors.
  • Fixed typo in the reported versions in setup.py to include python 3.4.

0.0.3:

  • Initial Release

Releases

No releases published

Packages

No packages published

Languages