Any interest in a Mid-Level API to UHD?

[mgw93]

I noticed this project when I wanted to interface with a USRP.
However, I found that the high-level has some restrictions (e.g. I didn’t see a way to add time_specs to receive operations),
and at the same time found the low level API a hassle to use with all the raw pointers.

I therefore started writing what I’d call a Mid-Level API, where all the functionality from the C-API is available but without having to deal with pointers.
The current work can be found here.
It’s not fully finished yet (some parts regarding sensors and subdev specs are still missing) and I didn’t get around to writing any documentation. But it should already be useable. And most of it is just wrappers around the Clang generated stuff, so it shouldn’t be too hard to use for someone familiar with the C or C++ API.

Is there any interest in integrating this code into this package?

[RGerzaguet]

Thanks for the comment.
You are absolutely right, and there is many place left for mid API for UHDBindings. In the current state, I only wrapped the functions I need in AbstractSDRs. For the rest I give some insight on how you can wrap the low level library (https://juliatelecom.github.io/UHDBindings.jl/dev/use_libuhd/)(here)
I see the work you have done, pretty tremendous. We should probably have a look on integrate this kind of bindings in UHDBindings. Not sure on how we can coexist with AbstractSDRs atm.
For the timing measure, I think that the function getTimeStamp(radio.rx) should do the trick though ?

[mgw93]

I have recently continued working on this. I am now at a point where I consider the project mostly complete. The only missing part that I am aware of are some functions regarding subdev specifications. Otherwise, all the Clang generated low level functions should now have an easier to use equivalent.
I have also added an example program to the README.

Should we try to integrate this code into your package? Otherwise, I’ll probably try to get it accepted into the Julia registry as its own package (that still depends on UHDBindings for the Low Level API though).

It might also be worth it to use this code as the backend for your High Level API.

[RGerzaguet]

Hello @mgw93
Thank you very much for the news and glad to see that you were able to make progress on the middleware for UHD. It's a driver that is not easy to handle.
I indeed think that the best solution is to offer a separate package. The goal of AbstractSDRs is to provide a high-level API with a relative abstraction of the nature of software-defined radios. The exported functions are rather functions that are valid for all the different SDRs (not always easy by the way) and this allows switching from one radio to another transparently. Therefore, a very comprehensive API is not necessarily ideal in the sense that it would need to have equivalents on the other backends.

However, it could be quite useful from a centralization // visibility point of view to propose this project within the JuliaTelecom organization, what do you think? I can invite you to the organization so that you can propose the repository within the complete ecosystem.
What do you think?

[mgw93]

Yes, that does seem reasonable.
I understand the challenges with trying to provide a uniform API to a heterogeneous set of hardware. Outside of the Julia ecosystem, I know that SoapySDR is trying to provide such an abstraction. I have however never interacted with it so far.

Going forward with offering my own code as a separate package, there are a few things I still want to clean up that probably result in breaking changes to the API. As far as I know, I’m currently the only user, so it shouldn’t be an issue, but should be done before advertising the package to a wider audience.
I also need to think about the name again. UHDAPI was just a provisional choice. I guess I should at least add .jl to the end as it seems to be customary for julia projects. UHD.jl would seem fitting, but it seems your project used to be under that name, so I’m not sure whether it’d cause any confusion.

On a somewhat more distant time scale, it would seem reasonable to include the low level bindings generated by Clang into my project, I however have no experience at all how these are generated. Once that is done, it might make sense to build your high-level API on the functions that my code provides.

I would also appreciate any feedback on the code and its overall design. Since this is my first larger project in Julia, I might be unaware of some conventions or best practices that are expected of a project in the Julia ecosystem.

[RGerzaguet]

Hello

Ok, let's do it this way. I've invited you to the organization.

Regarding the points you mentioned:

I also need to think about the name again. UHDAPI was just a provisional choice. I guess I should at least add .jl to the end as it seems to be customary for Julia projects. UHD.jl would seem fitting, but it seems your project used to be under that name, so I’m not sure whether it’d cause any confusion.

I think UHD.jl does not comply with Julia naming conventions. UHDAPI.jl is probably more appropriate, although I was told at the time that UHD is not well-known outside the SDR community and therefore might not be very clear. But I think it should be okay!

On a somewhat more distant time scale, it would seem reasonable to include the low-level bindings generated by Clang into my project, I however have no experience at all how these are generated. Once that is done, it might make sense to build your high-level API on the functions that my code provides.

That definitely makes sense.

I would also appreciate any feedback on the code and its overall design. Since this is my first larger project in Julia, I might be unaware of some conventions or best practices that are expected of a project in the Julia ecosystem.

Yeah, feel free to ping me when your repo is up. Not sure that I have all the best practices myself, but two heads are better than one!

In the meantime, I close this issue but feel free to re-open it (or another one) if you need
BR
@+R