Although currently unsupported in GSM core, enable TCH/H
support in Transceiver52M for testing and future availability.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@5169 19bc5d8c-e614-43d4-8b26-e1612bc8e597
The adaptive energy detection threshold does not scale relative
to signal level. In other words, the adjustment factor will be
the same whether the at 40% of signal level or 4%. If the receive
gain is reduced by a large amount, suppose 20 dB, the receiver
may take minutes to adjust to the new level.
When the receive gain is changed, reset the threshold back to
the initial level. This reduces issues of runtime gain adjustment
and prevents blocking bursts while the threhold level slowly
adjusts.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@4595 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
Put a floor on the transmit latency of the B100 in order to suppress
underruns in typical conditions. Empirical data from a handful of
relatively recent machines shows that the B100 will underrun when
the transmit threshold is reduced to a time of 6 and a half frames,
so we set a minimum 7 frame threshold.
The overall benefit should be marginal and may increase the
possibility of bursts arriving stale (after the trasmit deadline),
but will reduce the number of alarming UHD related messages that
appear in the log file.
This patch is UHD and B100 specific - USRP1 is unaffected.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@3980 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
If no bursts were received over a long enough duration
then the threshold would roll into negative territory.
The energy detection is based on a comparison with the
squared threshold, so all handsets would become
effectively barred after a certain period of
inactivity.
In theory, this bug also exists in the mainline tree,
but there the daughterboard receive gain is fixed at
max, which always allows the ADC to generate sufficient
noise to trigger the energy dectector and keep the
system in a valid steady state.
To fix, simply add a negative value check like those
already in place for other locations.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2655 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
The output of the modulator or resampler is scaled and
converted from floating point to fixed point. The scaling
factor is the leftover dB in RF attention (relative to max
transmit power), which is handled prior to the integer
conversion. This should work across all daughterboards and
non-UHD installations.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2650 19bc5d8c-e614-43d4-8b26-e1612bc8e597
Similar to the non-52 Mhz case,
589dd9091ef594ef6ef5804fbf6bfa70f3f02858
This drastically reduces underruns on the E100.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2648 19bc5d8c-e614-43d4-8b26-e1612bc8e597
Push the ability to set thread priority out to the 52M
Transceiver interface, because that's where the thread
control exists.
Signed-off-by: Thomas Tsou <ttsou@vt.edu>
git-svn-id: http://wush.net/svn/range/software/public/openbts/trunk@2644 19bc5d8c-e614-43d4-8b26-e1612bc8e597
ttsou