You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current codebase has an IRadio interface as well as classes for each major radio manufacturer (e.g. RadioKenwood, RadioIcom, etc.) Eventually we'd like to remove those and replace them with a HamlibRadio class that interfaces with the Hamlib library for CAT/PTT control. This can be done by doing the following:
Create a Hamlib project in the solution to store the wrapper C# interface. This wrapper provides a modern interface to Hamlib and hides the various required P/Invoke calls and marshalling.
Build 32 and 64 bit versions of Hamlib using MinGW (Hamlib unfortunately doesn't like being compiled by Visual Studio). Example of required command in the Hamlib source tree to set this up: ./configure --host=i686-w64-mingw32 --disable-static
For future use, also build a .dylib for macOS. ./configure from above doesn't need --host here but we should make this a universal ARM/Intel binary. This example from the FreeDV project on how to build a universal version of Hamlib is useful.
Update the Hamlib project/Paclink solution to store the DLLs created in (2) and (3) and copy them to the final build location for packaging by the installer. The copying to the final build location would only be needed for Windows and (future) Mac builds as Linux can use whatever the user's distro provides for the hamlib package.
Update the wrapper classes so that they can figure out which version of the DLL or .dylib to load. Useful documentation from Microsoft on how to accomplish that is here.
Update the Paclink project to properly display the radios available from Hamlib when the user needs to select one for CAT control, as well as create RadioHamlib when attempting a connection to the gateway.
Advantages of going with Hamlib instead of our own code:
Much wider support for radios overall. In addition, adding additional radios would be a simple matter of rebuilding the DLLs and .dylib.
We're able to take advantage of much more extensive testing of more radios done by users from a wide variety of ham radio related projects.
Disadvantages:
Needing to use P/Invoke adds some complexity. If we were able to build Hamlib in Visual Studio, it may be possible to build a C++ .NET assembly using both managed and unmanaged code to hide that complexity.
Possible licensing issues. Hamlib is LGPL, so we'll need to look at that closely to make sure there are no issues.
The text was updated successfully, but these errors were encountered:
The current codebase has an IRadio interface as well as classes for each major radio manufacturer (e.g. RadioKenwood, RadioIcom, etc.) Eventually we'd like to remove those and replace them with a HamlibRadio class that interfaces with the Hamlib library for CAT/PTT control. This can be done by doing the following:
./configure --host=i686-w64-mingw32 --disable-static
./configure
from above doesn't need--host
here but we should make this a universal ARM/Intel binary. This example from the FreeDV project on how to build a universal version of Hamlib is useful.Advantages of going with Hamlib instead of our own code:
Disadvantages:
The text was updated successfully, but these errors were encountered: