search

Hamlib / Hamlib

Ham radio control library for rigs, rotators, tuners, and amplifiers
Other
597 stars 205 forks source link

Documentation for get_ant command changes #195

Closed mikaelnousiainen closed 4 years ago

mikaelnousiainen commented 4 years ago

@mdblack98 The recent changes on get_ant (or y) command break existing Hamlib clients that use the command, as it now expects an argument.

1) Based on the code, all I can see is that there is an "option" added to get_ant and set_ant -- there is no documentation on what it means and how to use it, so it's difficult to understand how to update my Hamlib client.

2) Can we make the argument optional? Why make it mandatory in the first place?

3) Could you please update Hamlib documentation?

Thanks and 73, Mikael OH3BHX

N0NB commented 4 years ago

The antenna command had to be "broken" as it was did not work for current (and future rigs)....Icom rigs in particular. 4.0 has not been officially released yet and is still under development. This is the first thing we've had to do that breaks the ABI. The intent right now is this...which, as I said, is still under development and subject to change. Y Antenna OptionAntenna will be 1-based.  The Option flag right now only applies to some Icom rigs where you can set an antenna to Rx-only.  I can easily imagine this will expand in the future. y AntennaAntenna will be 1-based.  Antenna#0 will return the currently select antenna and it's option setting which you can ignore (defaults to 0 if rig doesn't have any Option capability) If you're interfacing to rigctld you can send a "y" command by itself and if you get prompted with Antenna: then it's the new version. I'll update the man page. de Mike W9MDB

On Sunday, February 9, 2020, 06:19:29 AM CST, Mikael Nousiainen <notifications@github.com> wrote:

@mdblack98 The recent changes on get_ant (or y) command break existing Hamlib clients that use the command, as it now expects an argument.

Thanks and 73, Mikael OH3BHX

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

Hamlib-developer mailing list Hamlib-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hamlib-developer

mikaelnousiainen commented 4 years ago

Ok, though I still don't understand why I need to give a parameter to get_ant. Shouldn't it simply return the current state (even if we can set both TX and RX antennas)?

The naming could be improved too -- having something called Antenna and Option does not really reflect what you're describing. And the get_ant command returns two Antenna rows, which is a bit confusing too.

Rig command: Y
Antenna: 1
Option: 2

Rig command: y
Antenna: 0
Antenna: 1
Antenna: 2

Also, now that we have antenna counts defined (at least for some Icom rigs), could we expose the antenna count also in rig capabilities?

N0NB commented 4 years ago

Because there are some rigs with more than 2 antennas.  So get_ant needs to know which antenna you want to query.And there's a difference between "current" antenna and each antenna setting. I'll check the return on the y command...definitely looks wrong.... Mike

On Monday, February 10, 2020, 01:58:31 AM CST, Mikael Nousiainen <notifications@github.com> wrote:

Ok, though I still don't understand why I need to give a parameter to get_ant. Shouldn't it simply return the current state (even if we can set both TX and RX antennas)? The naming could be improved too -- having something called Antenna and Option does not really reflect what you're describing. And the get_ant command returns two Antenna rows, which is a bit confusing too. Rig command: Y Antenna: 1 Option: 2

Rig command: y Antenna: 0 Antenna: 1 Antenna: 2

Also, now that we have antenna counts defined (at least for some Icom rigs), could we expose the antenna count also in rig capabilities?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub, or unsubscribe.___ Hamlib-developer mailing list Hamlib-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hamlib-developer

N0NB commented 4 years ago

OK...fixed the 'y' command. Please test my fork... https://github.com/mdblack98/Hamlib

I'll see about adding ant_count to the capabilities....right now there's no logical check being done on the antenna # or optiont requested...the rig should return an error for any bad values on those. Rig command: YAntenna: 1Option: 2 Rig command: yAntenna: 1Antenna: 1Option: 2 Rig command: y 1Antenna: 1Option: 2 Rig command: Y 2 1 Rig command: y 2Antenna: 2Option: 1

de Mike W9MDB

On Monday, February 10, 2020, 01:58:31 AM CST, Mikael Nousiainen <notifications@github.com> wrote:

Ok, though I still don't understand why I need to give a parameter to get_ant. Shouldn't it simply return the current state (even if we can set both TX and RX antennas)? The naming could be improved too -- having something called Antenna and Option does not really reflect what you're describing. And the get_ant command returns two Antenna rows, which is a bit confusing too. Rig command: Y Antenna: 1 Option: 2

Rig command: y Antenna: 0 Antenna: 1 Antenna: 2

Also, now that we have antenna counts defined (at least for some Icom rigs), could we expose the antenna count also in rig capabilities?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub, or unsubscribe.___ Hamlib-developer mailing list Hamlib-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hamlib-developer

mdblack98 commented 4 years ago

Arrghhh...gotta' figure out how to send only text formatting as this email list does not like the html email format here...

OK...fixed the 'y' command.

Please test my fork...

https://github.com/mdblack98/Hamlib

I'll see about adding ant_count to the capabilities....right now there's no logical check being done on the antenna # or optiont requested...the rig should return an error for any bad values on those.

Rig command: Y Antenna: 1 Option: 2

Rig command: y Antenna: 1 Antenna: 1 Option: 2

Rig command: y 1 Antenna: 1 Option: 2

Rig command: Y 2 1

Rig command: y 2 Antenna: 2 Option: 1

de Mike W9MDB

On Monday, February 10, 2020, 08:03:39 AM CST, Nate Bargmann notifications@github.com wrote:

OK...fixed the 'y' command. Please test my fork... https://github.com/mdblack98/Hamlib

I'll see about adding ant_count to the capabilities....right now there's no logical check being done on the antenna # or optiont requested...the rig should return an error for any bad values on those. Rig command: YAntenna: 1Option: 2 Rig command: yAntenna: 1Antenna: 1Option: 2 Rig command: y 1Antenna: 1Option: 2 Rig command: Y 2 1 Rig command: y 2Antenna: 2Option: 1

de Mike W9MDB

On Monday, February 10, 2020, 01:58:31 AM CST, Mikael Nousiainen notifications@github.com wrote:

Ok, though I still don't understand why I need to give a parameter to get_ant. Shouldn't it simply return the current state (even if we can set both TX and RX antennas)? The naming could be improved too -- having something called Antenna and Option does not really reflect what you're describing. And the get_ant command returns two Antenna rows, which is a bit confusing too. Rig command: Y Antenna: 1 Option: 2

Rig command: y Antenna: 0 Antenna: 1 Antenna: 2

Also, now that we have antenna counts defined (at least for some Icom rigs), could we expose the antenna count also in rig capabilities?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub, or unsubscribe.___ Hamlib-developer mailing list Hamlib-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hamlib-developer

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub, or unsubscribe .

mikaelnousiainen commented 4 years ago

Ok, that makes more sense now.

So each "Antenna" actually means an antenna switch and the "Option" is one of the selected antenna ports in that switch. Maybe we could still improve the wording, e.g. to use some words to distinguish between the logical antennas (= switches) usable by the rig and the actual antenna ports (= options).

(And please correct me if I'm wrong with my explanation)

I wasn't aware that some rigs could have more than one antenna "switch", but apparently that is true.

Thanks for the clarification!

mikaelnousiainen commented 4 years ago

As the antenna selection is getting more complicated, having new, dedicated rig capabilities would be a huge help for any application using Hamlib. We should of course have a model where we represent both the "switches" and the "ports/antennas", as each switch may have a different set of antenna ports available. In addition, the antennas/switches should have some metadata/attributes to express whether the antenna is an RX-only or RX/TX antenna.

mdblack98 commented 4 years ago

No..."Antenna" is whatever the rig understands to be "ANT1, ANT2, ANT3,...." "Option" is whatever the rig needs to set any options on that antenna port may support.

de Mike W9MDB

On Monday, February 10, 2020, 10:37:29 AM CST, Mikael Nousiainen notifications@github.com wrote:

Ok, that makes more sense now.

So each "Antenna" actually means an antenna switch and the "Option" is one of the selected antenna ports in that switch. Maybe we could still improve the wording, e.g. to use some words to distinguish between the logical antennas (= switches) usable by the rig and the actual antenna ports (= options).

(And please correct me if I'm wrong with my explanation)

I wasn't aware that some rigs could have more than one antenna "switch", but apparently that is true.

Thanks for the clarification!

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub, or unsubscribe .

N0NB commented 4 years ago

Yes...we need to implement an antenna model of some sort. Though I haven't seen where the capabilities are used much by anybody other than internal hamlib usage. Do you use the capabilities query?  What software are you writing?

Got to get the basics working first and then we can look at expanding it.

de Mike W9MDB

On Monday, February 10, 2020, 10:42:24 AM CST, Mikael Nousiainen notifications@github.com wrote:

As the antenna selection is getting more complicated, having new, dedicated rig capabilities would be a huge help for any application using Hamlib. We should of course have a model where we represent both the "switches" and the "ports/antennas", as each switch may have a different set of antenna ports available. In addition, the antennas/switches should have some metadata/attributes to express whether the antenna is an RX-only or RX/TX antenna.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub, or unsubscribe .

Hamlib-developer mailing list Hamlib-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hamlib-developer

mikaelnousiainen commented 4 years ago

Thanks for asking.

I'm developing (or have developed for the past 2 years, actually) a piece of software called Web Radio Control. It's a web-based remote control application that is based on Hamlib and Janus WebRTC gateway (to take care of audio I/O). The core idea is that you will need only a web browser and a Raspberry Pi (or a similar Linux-based computer) to control your rig. The software is using Hamlib capabilities extensively to expose all possible functionality of the radios/rotators in the UI. More recently, there have been some alternatives (such as RigPi) that offer similar functionality, but it wasn't the case when I started the project.

Web Radio Control has been tested actively by ~20-30 Finnish radio amateurs, so I've been able to collect some feedback and do testing with different sets of hardware. I'm about to create a proper website for the project during this spring (currently, we have only a site that documents the installation procedure and it's still Finnish-only). The software is not open source (and probably will not be, as being a "community manager/maintainer" for a hobby project of mine isn't something I wish to do). However, I'm happy to contribute to open-source projects that I use -- like I have done with Hamlib. My main goal with Hamlib has been so far to improve capabilities and add functions/levels/parameters to enhance remote control possibilities.

Here are some screenshots, if you're interested (again, the website is unfortunately in Finnish only, but will be translated later):

https://doc.webradiocontrol.tech/getting-started/screenshots/

There's also a mailing list (though the international side of it is still inactive, as we have a separate subgroup for Finnish users): https://wrc-users.groups.io/g/main -- I'll be making announcements there once the website and proper systems for licensing/download are set up.

N0NB commented 4 years ago

On my fork https://github.com/mdblack98/Hamlib.git

Just changed y and Y to be 1-based antenna numbers now.  antenna#0 will return current setting for y where #0 for Y is invalid. For real rigs y will return the TX antenna which seems to make the most sense....working on that one now.

Will be updating man pages next

dummy device emulates 4 antennas

Rig command: y 0 Antenna: 1 Option: 0

Rig command: Y 5 5 set_ant: error = Invalid parameter

Rig command: Y 4 4

Rig command: y 0 Antenna: 4 Option: 4

Rig command: y 1 Antenna: 1 Option: 0

de Mike W9MDB

On Monday, February 10, 2020, 12:01:46 PM CST, Mikael Nousiainen notifications@github.com wrote:

Thanks for asking.

I'm developing (or have developed for the past 2 years, actually) a piece of software called Web Radio Control. It's a web-based remote control application that is based on Hamlib and Janus WebRTC gateway (to take care of audio I/O). The core idea is that you will need only a web browser and a Raspberry Pi (or a similar Linux-based computer) to control your rig. The software is using Hamlib capabilities extensively to expose all possible functionality of the radios/rotators in the UI. More recently, there have been some alternatives (such as RigPi) that offer similar functionality, but it wasn't the case when I started the project.

Web Radio Control has been tested actively by ~20-30 Finnish radio amateurs, so I've been able to collect some feedback and do testing with different sets of hardware. I'm about to create a proper website for the project during this spring (currently, we have only a site that documents the installation procedure and it's still Finnish-only). The software is not open source (and probably will not be, as being a "community manager/maintainer" for a hobby project of mine isn't something I wish to do). However, I'm happy to contribute to open-source projects that I use -- like I have done with Hamlib. My main goal with Hamlib has been so far to improve capabilities and add functions/levels/parameters to enhance remote control possibilities.

Here are some screenshots, if you're interested (again, the website is unfortunately in Finnish only, but will be translated later):

https://doc.webradiocontrol.tech/getting-started/screenshots/

There's also a mailing list (though the international side of it is still inactive, as we have a separate subgroup for Finnish users): https://wrc-users.groups.io/g/main -- I'll be making announcements there once the website and proper systems for licensing/download are set up.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub, or unsubscribe .

Hamlib-developer mailing list Hamlib-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hamlib-developer

mikaelnousiainen commented 4 years ago

Ok, I'm still slightly confused :) Just to understand the use case for this, would you like to give a concrete example how a real hardware radio (you mentioned some Icom models require this?) would work with the antenna+option model? What do the options mean -- are they rig-specific?

N0NB commented 4 years ago

This was driven by the IC-7851

See the attached.  The options are rig-specific though some commonality will be seen.

So...to set ANT1 for TX and ANT 2 for RX this is where we are headed....still waiting for to get this completely implemented and tested.

Y 2 1 Y 1 0 The presumption here is that setting the antenna either way also selects it.....still to be determined....

de Mike W9MDB

On Monday, February 10, 2020, 02:03:36 PM CST, Mikael Nousiainen notifications@github.com wrote:

Ok, I'm still slightly confused :) Just to understand the use case for this, would you like to give a concrete example how a real hardware radio (you mentioned some Icom models require this?) would work with the antenna+option model? What do the options mean -- are they rig-specific?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub, or unsubscribe .

Hamlib-developer mailing list Hamlib-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hamlib-developer

mdblack98 commented 4 years ago

The attachment didn't come through....

On Monday, February 10, 2020, 03:14:38 PM CST, Nate Bargmann notifications@github.com wrote:

This was driven by the IC-7851

See the attached.  The options are rig-specific though some commonality will be seen.

So...to set ANT1 for TX and ANT 2 for RX this is where we are headed....still waiting for to get this completely implemented and tested.

Y 2 1 Y 1 0 The presumption here is that setting the antenna either way also selects it.....still to be determined....

de Mike W9MDB

On Monday, February 10, 2020, 02:03:36 PM CST, Mikael Nousiainen notifications@github.com wrote:

Ok, I'm still slightly confused :) Just to understand the use case for this, would you like to give a concrete example how a real hardware radio (you mentioned some Icom models require this?) would work with the antenna+option model? What do the options mean -- are they rig-specific?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub, or unsubscribe .

Hamlib-developer mailing list Hamlib-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hamlib-developer

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub, or unsubscribe .

mdblack98 commented 4 years ago

Fixed