Building against limesuite-ng

General Discussion
1

No issues building/compiling limesuite-ng as a test on 24.04. All went well.

The problem I’m seeing is after install when trying to build SatDump and/or SDR++ which both have native support for limesuite are unable to find the -lLimeSuite libraries and thus do not enable limesuite support.

It seems like there’s legacy API support in LimeSuiteNG but I’m wondering if the libraries are not found because everything seems to have ng added onto the name?

Is this a change needed in LimeSuiteNG or do all 3rd party applications providing native support of lime need something in cmake or elsewhere changed?

2

-lLimeSuite is the legacy library, you don’t have it installed on your system, so it can’t be found.

LimeSuiteNG does provide a legacy API interface, due to technical reasons it has been split into separate library, replace -lLimeSuite with -llimesuiteng-legacyapi, then it should succeed the build.

3

I’ll assess if there’s negative impacts, but instead of changing SatDump, SDR++, etc I simply made a symlink to the legacy api .so by way of a libLimeSuite.so.

Can you think of anything negative there?

4

Nevermind, that only got me so far. SatDump is looking for lms7_device.h which doesn’t seem is included in NG or I’m missing something else.

6

I’ll try the proper way you suggested of building and using the legacy api but it’s still not clear to me how that’ll overcome the missing .h files.

7

the lms7_device.h was a C++ header, it is not compatible with LimeSuiteNG. But looking at the code, it seems it’s content is only needed for the Android build SatDump/plugins/sdr_sources/limesdr_sdr_support/lime_sdr.h at 65aa43cd2040bafc7e33adcff5915ccc856e57cb · SatDump/SatDump · GitHub
So simply removing that header include should work.

8

Thank you so much! I didn’t even think to look, I’ll give it a shot and let you know.

9

Regardless I’d like ten is commented or the portion you mention it ends up with an issue on line 21 of lime_sdr.cpp where lime/lms have not been declared. I shared with the SatDump developers to see what’s the best way forward.

10

On the other hand, SDR++ is able to build as it appears it does not look for that header file. I still have to actually test it with my mini 2, but it did build.

11

In the case of SDR++ and the temporary workaround of making the additional symlink of LimeSuite.so to the legacy api (vs editing SDR++) allowed SDR++ to fully build the module. I then tested running SDR++ with a Lime mini2. The lime mini2 was usable via NG’s legacy api in the brief test I performed.

I’m assuming the answer is no as I imagine there would be various conflicts - both LimeSuite and LimeSuiteNG cannot be installed at the same time, right? Soapy, the GUI, and more would have conflicts?

For SatDump I would probably have to wait for it to support NG directly or seek other ways around the lms7_device being needed?

Also slightly off topic, but since NG includes GNU Radio blocks - I assume gr-LimeSDR is no longer needed?

12

They both can coexist, there are no conflicts. The only overlap is the legacy lime/LimeSuite.h header file, but it’s identical on both sides and not going to be changed anymore.

not yet, gr-limesuiteng is not yet feature equivalent to gr-limesdr. So until remaining features are added, you can have both plugins installed.

13

That’s good to know. I thought for example, the limesuite gui or soapy plugin, would end up being present twice?

14

Maybe a better question would be - how would you recommend building the original limesuite in such a way that all the command line tools (assuming duplication?) would not overlap?

Thinking maybe I should have both present or at least give it a shot.

15

There are no duplications or overlaps (except that header file), so nothing special needs to be done, from files perspective. Both projects can be built and installed on the same system.
Things might get tricky, if both libraries would have to be active at the same time in the same process (For example, you can’t compile time link to both libLimeSuite.so and liblimesuiteng-legacyapi.so, because they have functions with the same names. But you could load dynamically one or the other… basically C/C++ symbols linking nuances).

16

Found another application that leans heavily on native LimeSuite support, however, the legacy LimeSuite-NG api unfortunately doesn’t cover what qradiolink is needing.

For example

There’s a lot of other places it’s woven in.

I’ll have to look more into both apis present like you previously mentioned.

17

LimeSuiteNG has “limesuiteng/DeviceRegistry.h”, the API acts in the same way, just represents a whole device, not just a data connection as before.

18

Thank you, and for limeRFE.h, is there a replacement for that? Thought I’d ask before going the route of both apis present.

19

I figure I’ll give the dual API a go. What would you recommend disabling on LimeSuite so as to not conflict with NG?

So far I have the GUI and Soapy off. I’m not sure if I should disable UtilCommand, QuickTest, SuiteExamples, and the three Connections.

20

I’m assuming the same applies to LMS7002M_parameters.h as well?

I have both installed now and I noticed that file existed in both.

21

currently there is no limeRFE support in LimeSuiteNG.

Nothing. The only conflicts can be in linking stage if using both libraries.

yes