Hello,
I stopped with Limesdr-Mini because with Osmo-trx it worked for a few minutes and then I had a bug.
I just understood that the problem is because of the Limesdr-Mini clock, is that correct ?
On the Osmocom website it is written :
Using external clock reference
providing an external clock is tricky:
according to the spec from the clockchip used (ti LMK00105) the input signal needs to have “sharp rectangles 2V/ns or better”.
this is a limitation of the LimeSDR mini due to no extra pll chip being present, in contrast to the LimeSDR-USB.
If I order a Limesdr-Mini today, will the “Leobodnar - Mini Precision GPS Reference Clock” external clock fix the problem ? (Mini Precision GPS Reference Clock : Leo Bodnar Electronics)
I’m looking for an external clock that can be powered by usb.
Normally, moving the resistance is enough ? In addition to putting the parameters in LimeSuite each time you start ?
That’s a lot of questions, sorry.
What do you mean by “a bug”? Did the transceiver application crash/exit?
I’ve seen OsmoTRX crash before due to general stability or performance errors and messages produced which might be interpreted to be a clock problem, when in fact it was to do with a bad build or configuration etc. We’ve used this fine without an external clock and just using the one onboard.
I’d imagine not if the problem is OsmoTRX crashing. If the issue is frequency accuracy/stability and handsets not being able to find the network or register, then perhaps, but I’d suspect a more fundamental problem.
Note also that you can use kalibrate-lms to calibrate the TCXO using an existing macro cell.
This obviously isn’t as good as using a GPSDO, but should improve on frequency accuracy.
Thank you very much for your answer.
The problem was with OsmoTRX, for OpenBTS or OsmoBSC, NITB …
OsmoTRX works normally, phones register and make calls.
But after a few minutes, OsmoTRX turns red and scrolls quickly. I lose the network and I have to restart everything.
I am on a pc in I7-8700k but on VMware. The construction is done correctly and so is the configuration. I don’t think of a fundamental problem.
I had not tried kalibrate-lms.
I had the LimeSDR and LimeSDR-Mini with the same problem. I now thought about the clock compared to what is written on the OsmoTRX site.
I have exactly the same problem as here :
LimeSDR-Mini and osmo-trx not stable with OpenBTS - Applications / Cellular - MyriadRF Discourse
If you can help me understand the problem , I’ll buy a LimeSDR-Mini for further testing.
The SDR realtime applications are not intended to run inside of virtual machines (except rare conditions). Try to use bare-metal Linux installation.
1 Like
Exactly, we have run apps inside VMs before, but it’s generally a recipe for headaches.
Thanks a lot for your help.
VMware is mandatory for my tests.
I will try to do the test with another SDR.
It’s going to be problematic. With SDR workloads it’s not uncommon to run a real-time Linux kernel and do everything you can to minimise latency. This is in no way specific to LimeSDR hardware and you’ll find application notes detailing such steps for other vendors and in SDR software projects. Running an IT grade hypervisor is working to do the exact opposite.
There are VM solutions which would be better suited, but they are very different to VMware and typically allocate resources in a static manner upon start-up, where changes may even mean recompilation. Dynamic resource allocation and deterministic behaviour do not sit well together.
Okay.
Thank you very much for this valuable information.
I’ll do some research.
I haven’t got round to trying them yet, but promising candidates for providing a real-time VM that may be suited to running SDR workloads include:
1 Like
