LimeSuiteGUI together with API access


I recently got an LimeSDR board and have followed the blog posts and done some different tutorials etc. I have mostly been playing around with GNU radio (with osmo) but have also been looking at using the soapySdr API directly. Still, I feel it is cumbersome to play with the analog parameters and settings on the LMS7002M. Is it possible to handle the digital parts in GRC, but to fine tune the LMS7002M via the LimeSuiteGUI? When GRC is up and running and I try to connect with the LimeSuiteGUI it simply says that the board is busy(:

If this is not possible, do you have any recommendations on how to do more advanced LMS7002M settings when running grc?

You can’t have two processes accessing it at once and I think any settings will get lost due to the LMS7002M being reset when you (dis)connect.

There has been discussion about creating a configuration block for GRC to allow you to apply settings, at the very least via loading an INI file generated with Lime Suite, but possibly also with direct access to some of the more commonly used settings (there are many which are only of concern in e.g. optimising energy usage).

@joshblum, do you have any suggestions?

After thinking about this more. I had the idea that if limesuite had a server/client for the registers we could re-use the very fine grained gui to manipulate a lot of existing applications while they are running.

  • So when a limesuite device is running, it can be started with a “server” option for the register access. This could be implemented on sockets, IPC, dbus messages, etc. But basically like a server on the localhost.
  • Then we have a new limesuite device that inherits from iconnection and all that, except that it just proxies for the register access over the IPC, and otherwise does not implement streaming and things of that nature.

So from the limesuite gui perspective, this device shows up in the connection list once lets say, GRC has been run with driver=lime; and then you can connect to it and twiddle registers potentially. I know the GUI tends to re-initialize the LMS7 when opened and can even take down streaming, so there are some precautions to take. But we could run a lot further with the existing software this way, and get a lot more utility out of it.

Sounds like a great solution and something that would be really useful. Please update if someone will try to implement this. Unfortunately such an implementation is out of my league(:

There’s ‘RemoteControlTest’ branch which tried such concept, it works, but needs more refinement on the server/client port selection, as the values were just hardcoded for testing.