5 Jun
2018
5 Jun
'18
7:54 a.m.
Hi Antony,
On Tue, Jun 05, 2018 at 01:14:13PM +0200, Antony Lemmens wrote:
I had trouble with the osmo-trx-uhd and LimeSDR (like
in Bug #2723), so I
tried the branch "laforge/lime".
yes, unfortunately we haven't had much success in getting OsmoTRX to run
stable with LimeSDR so far. It works like a charm with other hardware, though.
The result is that the LimeSDR apparently transmit
successfully data (my MS
display correctly the MCC/MNC and the spectro shows the correct frequency)
but it seems that the LimeSDR/driver/not-sure-what does not receive any
signal in return.
This is exactly where the development status is for us. We then got side-tracked
with various problems introduced with more recent LimeSuite releases, as well
as with problems related to the hardware we received at sysmocom.
Transmit didn't work reliable for us with LimeSDR-mini HW v1.0 nor with the
large LimeSDR, while it did seem to work fine with LimeSDR-mini HW v1.1.
I don't think it makes sense to work on the Rx side until Tx works reliable at
least on the regular LimeSDR as well as LimeSDR-mini v1.1, and
preferably with latest LimeSuite releases rather than having to pin to
some old versions.
It all feels like it's Lime* is currently still a very moving target. With
LimeSDR-mini v1.1 (where Tx waveform looks great) we even have trouble
getting the most basic LMS_Open() to work reliably, see
http://osmocom.org/issues/2919#note-11 :(
I know that it is a work in progress, and if you need
some feedback or
tests, do not hesitate to ask.
Thanks for your offer, it's much appreciated. You could provide any feedback
from testing at http://osmocom.org/issues/2919 and describe any "known working"
setup of hardware (+version), gateware, limeSuite in all detail.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)