I really hope that this email will get to you.
My name is Dex (YO3HEX) and i'm working right now on quite a big project that would allow the remote operation of up to 2 transceivers without any PC on the remote side (that includes bidirectional streaming, cat 2 ethernet and a remote keyer just to name a few).
First of all I would like to give the team a big thank you for the impressive work that you've done.
In my case i'm working on a small PC application that would allow the use of the cat 2 ethernet endpoint to control various transceivers on the other side and this lib fitted as a glove - given the fact that i'm using C# as my main development platform (one of the main reasons being the GUI) i had to create a little bit of a wrapper to expose the DLL methods / functionalities in C# but, everything works as expected and as good as it gets - there were some small problems in regards to data serialization and to the fact that as far as i understand the lib is not necessary thread safe but nothing a good ol' mutex cannot solve.
There is a small thing that I would like to discuss if you have the time in regard to the power on and power off functionality that is present in the hamlib (yes i do understand quite well that there are some limitations).
The scenario is like this - regardless if using rigctl or my own software - but i will refer to rigctl because it is easier to test.
Scenario 1 - rig is in power on state (icom 7300 for example) and i connect to the rig using rigctl - i'm issuing a power off command which would bring the rig in power off state as expected, i'm issuing then a power on command that is bringing the rig in power on state as expected - so this is working as intended.
Scenario 2 - rig is in power off state - rigctl will cont connect to the rig - which i do think is kinda by design because it would be expected that the rig would reply with some data when rigctl tries to query it - but in case of many transceivers the cat interface would listen only for power on frames (which is the case of 7300 for example) and in this case would not reply to any other types of cat queries - in this scenario, if rigctl is disconnected from the rig after a power off there would be no way to turn it back on (maybe i'm wrong and there are other parameters that can be passed to rigctl which i might have missed or i do not know about - by no means i did not review the whole code of hamlib)
As a final word i'm sending you some screens with the application that i'm working on, which right now is on the development phase (mouse wheel would also allow to modify the VFO when mouse is over the VFO display) and yes everything works stellar - again thank you for the magnificent work that the team have done.
Hello,
I really hope that this email will get to you.
My name is Dex (YO3HEX) and i'm working right now on quite a big project that would allow the remote operation of up to 2 transceivers without any PC on the remote side (that includes bidirectional streaming, cat 2 ethernet and a remote keyer just to name a few).
First of all I would like to give the team a big thank you for the impressive work that you've done.
In my case i'm working on a small PC application that would allow the use of the cat 2 ethernet endpoint to control various transceivers on the other side and this lib fitted as a glove - given the fact that i'm using C# as my main development platform (one of the main reasons being the GUI) i had to create a little bit of a wrapper to expose the DLL methods / functionalities in C# but, everything works as expected and as good as it gets - there were some small problems in regards to data serialization and to the fact that as far as i understand the lib is not necessary thread safe but nothing a good ol' mutex cannot solve.
There is a small thing that I would like to discuss if you have the time in regard to the power on and power off functionality that is present in the hamlib (yes i do understand quite well that there are some limitations).
The scenario is like this - regardless if using rigctl or my own software - but i will refer to rigctl because it is easier to test.
Scenario 1 - rig is in power on state (icom 7300 for example) and i connect to the rig using rigctl - i'm issuing a power off command which would bring the rig in power off state as expected, i'm issuing then a power on command that is bringing the rig in power on state as expected - so this is working as intended.
Scenario 2 - rig is in power off state - rigctl will cont connect to the rig - which i do think is kinda by design because it would be expected that the rig would reply with some data when rigctl tries to query it - but in case of many transceivers the cat interface would listen only for power on frames (which is the case of 7300 for example) and in this case would not reply to any other types of cat queries - in this scenario, if rigctl is disconnected from the rig after a power off there would be no way to turn it back on (maybe i'm wrong and there are other parameters that can be passed to rigctl which i might have missed or i do not know about - by no means i did not review the whole code of hamlib)
As a final word i'm sending you some screens with the application that i'm working on, which right now is on the development phase (mouse wheel would also allow to modify the VFO when mouse is over the VFO display) and yes everything works stellar - again thank you for the magnificent work that the team have done.
73 DE YO3HEX / YP3X
Dex