12 Apr
2019
12 Apr
'19
6:02 p.m.
On 4/12/19 4:05 PM, Rafael Diniz wrote:
ps: what would help me out a lot, would be if
every bugreport not only
references 'limesdr' but also has detail of:
* which model (mini, usb, net-micro?...) and revision?
* which gateware and firmware release was installed?
* which limesuite release or git version?
kind regards
--
- Joachim Steiger <jsteiger(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Harald Welte
It is a SDR hardware, but conceived, as far as I
understand, with GSM
usage in mind, considering the integrated GPSDO and so on. As soon as I
put my hands on it I'd like to evaluate if it's worth invest some time
to develop a housing for it and appropriate connections for a very low
power and low cost BTS.
i have gotten it to work quite fast with help of the patchset i am
working on.
it behaves mostly like a limesdr mini with a few addons and proper clock.
you currently also need limesuite git master, the tagged 19.01 is too old.
>> With the USB3 LimeSDR, after a few hours I
_always_ get a broken trx,
>> with lots of failure messages...
i have the same problem.
i usually i only use usb2 due to it being much more solid that way.
it should not matter anyhow, since we only need low bandwith for gsm.
> I'm sorry to hear this. We're trying to
address various problems
> related to LimeSDR devices for quite some time, but progress is
> unfortunately not as quick as one would hope, particularly as LimeSuite
> also evolves and every major version seems to behave quite differently,
> at least in the way how OsmoTRX is using the API.
well.. there are a couple of things coming together:
limesuite did indeed change its behaviour when it comes to a few things.
* it got more streamlined and with it the default settings. e.g.
channel0 isnt enabled by default anymore.
* some not defined behaviours changed, on which we relied.
* i have reordered some of the function calls we do:
limesuite doesn't like if you do your filtersetup, frequency, gain,
streaming setup and calibration setup in the wrong order. sadly, neither
our code nor lms has enough asserts to have anybody notice this soon enough.
the good news is: the crew of lime is completely on mission helping us
get this sorted.
> In recent weeks, Joachim has been making very good
progress with help
> from Lime to resolve some of the most long-standing issues related to
> RF compliance of OsmoTRX on LimeSDR (phase noise, burst shape, ...).
> There should be a patchset pushed to gerrit soon which will address this
> one class of problems. However, this does not adress any USB stability
> related problems, which is a separate class of issues. We have to look
> at them once as a time
ack, also see below
This is great, thanks for the report! I hope to have
USB problems put
aside with the LimeNET Micro, this is one of the reasons of my question.
not really. there IS a spi (or rather 2) connection(s) inbetween the
fpga and the rpi according to the documentation, but there is also the
ftdi601 bridge like used on the lime mini on the board.
this is afaik due to the spi link not achieving high enough bandwidth to
satisfy all involved.
since the rpi is only usb2, this is also limited.... but i dont see any
major issues for using it as a gsm trx.
One thing
I'm a bit missing here is: Where are your comprehensive bug
reports about this in the osmocom issue tracker? Particularly with
problems that manifest themselves only every few hours and hence are
not quick to reproduce, we have to collect those issues and related
log files, backtraces, ... in the issue tracker.
I'll do this in the next couple of days, sorry for sending the email in
advance of the actual bug report.