# AVMU Interface
Python 3 interface to AKELA Inc's vector meaurement units.
[Complete API Documentation here](https://akelainc.github.io/avmu/index.html)
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 https://github.com/AkelaInc/avmu/pull/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