With the introduction of the B100, there is USB support
using UHD devices. The characteristics of the trasmit
side burst submissions are more reflective of the bus
type than the device or driver.
Use a fixed latency interval for network devices and the
adaptive underrun approach for USB devices - regardless
of driver or device type.
The GPMC based transport on the E100 appears unaffected
by either latency scheme, which defaults to network.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
The resampling transceiver is unified with the 52MHz
version. The option to resample 400ksps from the device
to a GSM appropriate 270.833ksps is enabled at compile
time with the following option.
./configure --with-resamp
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
The readSamples call does not return less than the
number of samples requested. Doing otherwise is a
fatal error. So on overruns, which are not fatal,
continue reading until the requested number of
samples is received.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
Pipe the following uhd message types to standard warning
levels (INFO, WARN, ERROR) respectively. Ignore fastpath
logging messages and, instead, catch them from the
asynchronous device interface.
enum type_t{
status = 's',
warning = 'w',
error = 'e',
fastpath= 'f'
};
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
Unused and causes the follwing errors on certain UHD versions.
"ValueError: unhandled clock configuration reference source: _external_"
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
If the master clock rate fails to set - this basically only happens
when the wrong transceiver is choosen for the particular device -
the error is fatal and the transceiver should exit. The clock rate
setting was previously never verified.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
UHD recently modified the E100 type name from 'usrp-e' to
'e100' causing the device make to fail. Remove device type
checking to keep things working with the older and newer
names.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
Receive buffer flush should continue to read until
either the desired number of packets has been read or
timeout, which means that the buffer has been emptied.
These are expected behaviours and should return true.
Ignore errors at this stage as the data and associated
metadata can be considered garbage and not worth
reporting. Actual error conditions will be caught
further downstream when useful data comes in.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
Bump abnormal asynchronous events - basically send errors -
up to ERROR level. These errors are dominated almost
entirely by underflow events, which should not be regularly
occuring.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
UHD will internally accept floats with a range of +/-1.0,
which corresponds to a 16-bit signed integer range of
apporximately +/- 32000. Set the default amplitude to .3,
which is a safe value agaist saturation elsewhere in the
transmit chain.
The non-UHD maximum amplitude is unchanged at 13500.
Remove digital gain control because it's unnecessary and
causes extra load on enbedded systems.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
This is primarily a minor refactor with the exception
of non-recoverable errors - notably if the receive times
out - which almost always requires a reload of the FPGA.
In these cases, quit without trying as resistance is
futile.
ERROR_TIMING: Soft restart of streaming
ERROR_UNHANDLED: Benign errors
ERROR_UNRECOVERABLE: Abandon ship
Non-recoverable behaviour has not been observed in recent
builds, but may exist in older (or future) configurations.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
Overnight testing shows that this shouldn't be required
in the majority of cases, but shit happens. Enabling
this forces transmit timing realignment at one minute
intervals. As a fallback method, timing slips not
caught by normal checks will be reset at the update.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
At startup, instead of flushing initial packets blindly,
send a stop streaming command, flush, and start. The same
procedure is used in the event of a runtime timestamp
validity error.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
On a lapses of time monotonicity (and possibly other errors),
stop and restart the receive streaming with a buffer flush
in between. This is a cleaner replacement to the previous
clock reset with that didn't attempt to stop steaming.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
Type size_t was used in the UHD time_spec_t to integer
conversion, which would overflow at roughly 4 and a half
hours causing the sample buffer to error on timestamp
validity. Builds where size_t takes on 64-bits were not
affected by this bug.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
With UHD b4fc0d61bb6cbd1a5614745bab9aeb0abc22cb6f
Sample clock will reset to zero after an overrun. Earlier
versions may hang the FPGA, which is non-recoverable,
requiring a manual image reload or reboot.
If reset to zero, attempt to kick the sample clock to the
last properly received timestamp value. At this point,
there will be a timing continuity jump, which will drop
connections, but transmit and receive chains should be
aligned allowing for re-establishment.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
Shadow all gains and frequencies, which minimizes device access.
This allows the transceiver to variably control the device
settings.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
This shouldn't matter much, but the gain settings through the
interface are short circuited right now, which makes this a
problem.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
The value is used to align transmit and receive time slots within
a sample. This oscilloscope measured value is close, but may
need minor tweaking.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
Occasionally, the E100 will have errant timestamps at start
related to previous sessions. Early packets will be thrown
out anyways, so do this explicitly so the timestamps don't
royally fuck up the sample timing.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
These are mostly identical changes as added to the non-52MHz
implementation with the exception of sample rate.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
Thomas Tsou