This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Rafael Diniz rafael at rhizomatica.orgBtw, before any bug report (as I need to upgrade the limesuite and rebuild stuff), after some time running osmo-trx-lms (from osmocom nightly builds), I get: (...) <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len 2500 expect 3f19c154 got 3f19e134 (3f19e134) diff=1fe0 <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len 2500 expect 3f19cb18 got 3f19eaf8 (3f19eaf8) diff=1fe0 <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len 2500 expect 3f19d4dc got 3f19f4bc (3f19f4bc) diff=1fe0 <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len 2500 expect 3f19dea0 got 3f19fe80 (3f19fe80) diff=1fe0 <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len 2500 expect 3f19e864 got 3f1a0844 (3f1a0844) diff=1fe0 <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len 2500 expect 3f19f228 got 3f1a1208 (3f1a1208) diff=1fe0 <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len 2500 expect 3f19fbec got 3f1a1bcc (3f1a1bcc) diff=1fe0 <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len 2500 expect 3f1a05b0 got 3f1a2590 (3f1a2590) diff=1fe0 (...) Rafael Diniz On 4/15/19 9:12 AM, Rafael Diniz wrote: > Hi Joachim, > > This is all very encouraging! I did not even know the Lime could work > with USB 2 - thanks! > > I just realized I have limesuite18.06 (from debian repo) and > limesuite18.10 (osmocom repo), but I'll upgrade it to git, re-compile > everything and re-run all previous tests I did here. > > Kind regards, > Rafael Diniz > > On 4/12/19 1:02 PM, Joachim Steiger wrote: >> >> >> On 4/12/19 4:05 PM, Rafael Diniz wrote: >> >>> 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. >> 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 >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190415/272835d7/attachment.bin>