Replace the polyphase filter and resampler with a separate
implementation using SSE enabled convolution. The USRP2 (including
derived devices N200, N210) are the only supported devices that
require sample rate conversion, so set the default resampling
parameters for the 100 MHz FPGA clock. This changes the previous
resampling ratios.
270.833 kHz -> 400 kHz (65 / 96)
270.833 kHz -> 390.625 kHz (52 / 75)
The new resampling factor uses a USRP resampling factor of 256
instead of 250. On the device, this allows two halfband filters to
be used rather than one. The end result is reduced distortial and
aliasing effecits from CIC filter rolloff.
B100 and USRP1 will no be supported at 400 ksps with these changes.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@6733 19bc5d8c-e614-43d4-8b26-e1612bc8e597
UHD will throw if something goes awry in these sensitive sections,
so we should catch and shutdown gracefully. There is no recovery
if we can't set rates.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@6724 19bc5d8c-e614-43d4-8b26-e1612bc8e597
Remove the built time resampling selection and link both options.
Move the normal push/pullBuffer() calls back to the base class and
overload them in the inherited resampling class.
USRP2/N2xx devices are the only devices that require resampling so
return that resampling is necessary on the device open(), which is
the point at which the device type will be known.
The GSM transceiver only operates at a whole number multiple of
the GSM rate and doesn't care about the actual device rate and
if resampling is used. Therefore GSM specific portion of the
transceiver should only need to submit the samples-per-symbol
value to the device interface.
Then, the device should be able to determine the appropriate
sample rate (400 ksps or 270.833 ksps) and if resampling is
appropriate.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@6723 19bc5d8c-e614-43d4-8b26-e1612bc8e597
Periodic timing alignment should never be required for UHD devices,
though the mechanism was used as a fallback mechanism should UHD
not properly recover after an underrun - as may occur in old
003.003.000 based revisions. This issue is not a concern in more
recent UHD releases and deprecates this code for legacy USRP1
use only.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@6721 19bc5d8c-e614-43d4-8b26-e1612bc8e597
Previously, two timing correction values were used for UHD devices
depending on the sample rate of 270.833e3 or 400e3 for native GSM or
resampled device rate respectively. The correction values compensate
for residual timing effects due to analog component delays, filters
lag times, and general fudge factors. These values are device
specific and over-generalized by the two value configuration.
This patch adds the following struct to store these correction
values by device type and sample rate - through samples-per-symbol.
struct uhd_dev_offset {
enum uhd_dev_type type;
int sps;
double offset;
};
Signed-off-by: Thomas Tsou <tom@tsou.cc>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@6720 19bc5d8c-e614-43d4-8b26-e1612bc8e597
UHD device type was previously detected, but only categorized in
terms of bus type, USB or Ethernet, and sample rate capability.
With the number of supported device increasing, we can no longer
easily group devices since we need to handle more and more
device-specific peculiarities. Some of these factors are managed
internally by the UHD driver, but other factors (e.g. timing
offsets) are specific to a single device.
Start by maintaining an enumerated list of relevant device types
that we can use for applying device specific operations. Also
rename the USB/Ethernet grouping to transmit window type because
that's what it is.
enum uhd_dev_type {
USRP1,
USRP2,
B100,
NUM_USRP_TYPES,
};
Signed-off-by: Thomas Tsou <tom@tsou.cc>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@6719 19bc5d8c-e614-43d4-8b26-e1612bc8e597
This patch is long overdue and can now be merged after better understanding
of timestamp stability issues. UHD tick / timespec conversions were
generally used with the streamer interface, though these calls are actually
independent change sets. The combination would lead to internal rounding
errors and a timing drift most notably on B100 running at GSM symbol
rate multiples. There are no known issues, however, with the streamer code
itself.
The aforementioned issue was discovered in test code only, which was never
merged to mainline.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@6718 19bc5d8c-e614-43d4-8b26-e1612bc8e597
1)I did an experiment and compiled OpenBTS with clang yesterday, which
immediately highlighted two potential bugs in the Transceiver52 code.
I'm not sure they are indeed bugs and not the intended behavior, but
they look very much like that. The first one is below and the second
one is in the following mail.
GSM::Time() arguments are defined like #define USB_LATENCY_INTRVL
(10,0), which means that they are expanded into GSM::Time((10,0)).
This expression is a GSM::Time() with a single parameter where (10,0)
return value of the last argument, 0 in this case. I.e.
GSM::Time((10,0)) is equivalent to GSM::Time(0). I think this was not
the intention.
2) Printing \n after every complex number breaks output when you want to
print it in a single line, e.g. in many debug output.
I do not claim any copyright over this change, as it's very basic.
Looking forward to see it merged into mainline.
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@4515 19bc5d8c-e614-43d4-8b26-e1612bc8e597
UHD accepts optional 'args' that can be used for device descriptions
such as IP address, device type, etc. Allow these to be passed in on
the transceiver command line as the third argument (number of supported
carriers is the second argument). This option benefits those who may
have multiple UHD devices attached to a single system.
This option is not yet supported by GSM core and requires starting the
transceiver independently on the command line. This option has no
effect when USRP1 is used.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@4315 19bc5d8c-e614-43d4-8b26-e1612bc8e597
The appearance of underruns on B100 due to the latency transmit
window scares people. These should not be logged at ERROR level
because the events are generally not real errors. So use the same
behaviour of USRP1 of not logging these events. The presence of
underrun events can be determined by changes in the latency window
that is shown with log level set at INFO.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@3988 19bc5d8c-e614-43d4-8b26-e1612bc8e597
Allowing the underrun flag to reset will prevent a single event from
causing large jumps in the transmit latency threshold. This should
keep unreasonable timing latencies from occurring (e.g. latencies of
20+ frames).
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@3981 19bc5d8c-e614-43d4-8b26-e1612bc8e597
The "Loss of monotonic time" error occurs when a timestamp
arrives from the device that is earlier in time than the
previous timestamp. The output is an ALERT level message
generally accompanied by a transmit side timeout from the
device.
UHD: Loss of monotonic time
UHD: Loss of monotonic time
UHD: Device send timed out
Add to the error description the timestamp values that
generated the error and output with ALERT rather than
ERR log.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@3307 19bc5d8c-e614-43d4-8b26-e1612bc8e597
The failure "UHD make failed" implies that a suitable device
was found, but construction failed. Output the the found
target device information along with message.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@3181 19bc5d8c-e614-43d4-8b26-e1612bc8e597
Unrecoverable device errors include send and receive
timeouts and mangled packets. Other device errors, such
as non-monotonic timestamps are sometimes recoverable
through a soft restart.
These fatal are generally limited to development
versions of UHD driver or device firmware, but can occur
in release versions.
Alert user on such device errors along with current UHD
version.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@3012 19bc5d8c-e614-43d4-8b26-e1612bc8e597
Device errors regarding properties such as sample
rate or frequency tuning are almost always fatal and
lead to the common error "assuming TRX is dead".
Make sure that these errors are clearly presented to
the user.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2700 19bc5d8c-e614-43d4-8b26-e1612bc8e597
Perform a UHD device search before constructing the object,
and inform the user if no device is found.
No device found is the most common reason for the transceiver
to fail with the dreaded error "assuming TRX is dead".
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2699 19bc5d8c-e614-43d4-8b26-e1612bc8e597
This configuration is invalid because of FPGA based timestamp
support for the USRP1 in the UHD driver.
Kindly inform the user to recompile with libusrp support from
GNU Radio.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2698 19bc5d8c-e614-43d4-8b26-e1612bc8e597
Before setting the master clock rate, make sure that the
device is capable of being set. For now, assume that devices
that operate with default clock rates above 64 MHz,
specifically USRP2/N200/N210, cannot be set at 52 MHz.
Inform the user that these devices can be used with the
compile time option of host based resampling.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2697 19bc5d8c-e614-43d4-8b26-e1612bc8e597
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>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2677 19bc5d8c-e614-43d4-8b26-e1612bc8e597
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>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2672 19bc5d8c-e614-43d4-8b26-e1612bc8e597
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>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2671 19bc5d8c-e614-43d4-8b26-e1612bc8e597
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>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2663 19bc5d8c-e614-43d4-8b26-e1612bc8e597
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>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2661 19bc5d8c-e614-43d4-8b26-e1612bc8e597
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>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2659 19bc5d8c-e614-43d4-8b26-e1612bc8e597
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>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2656 19bc5d8c-e614-43d4-8b26-e1612bc8e597
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>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2654 19bc5d8c-e614-43d4-8b26-e1612bc8e597
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>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2653 19bc5d8c-e614-43d4-8b26-e1612bc8e597
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>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2652 19bc5d8c-e614-43d4-8b26-e1612bc8e597
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>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2651 19bc5d8c-e614-43d4-8b26-e1612bc8e597
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>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2647 19bc5d8c-e614-43d4-8b26-e1612bc8e597
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>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2646 19bc5d8c-e614-43d4-8b26-e1612bc8e597
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>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2645 19bc5d8c-e614-43d4-8b26-e1612bc8e597
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>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2638 19bc5d8c-e614-43d4-8b26-e1612bc8e597
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>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2635 19bc5d8c-e614-43d4-8b26-e1612bc8e597
