Thread: [Hamlib-developer] How to handle partial functions?
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
hamlib-developer
|
From: George B. <geo...@gm...> - 2024-09-10 20:40:03
|
I have been working on implementing rig_{get|set}_clock for the Kenwood
TS-890S/990S and need some advice on handling a quirk in the way the
clock interacts with other functions.
The rigs each have two clocks, called the local clock and auxiliary
clock (or secondary.) Common practice is to set the local clock to
local time and the aux to UTC. Only the local clock is directly
settable; it looks like the rig subtracts the local TZ offset to find
UTC, then uses the aux offset (in this case zero) to set the aux. Both
offsets are settable.
The two rigs are network-capable, and when connected they have the
option to sync the base clock(UTC) via NTP. When this is enabled the
clock setting function is disabled, both by CAT and the menu system;
only the offsets can be changed.
The problem I have is what to do with the single rig_set_clock() call.
I can't set the clock, but I'd like to set the offset (at least twice a
year). Do I just fail the whole thing? Do I ignore the clock if all of
YMDhms = 0? Set the offset first and bail if clock setting is
disabled? And what kind of result/status do I report? Any way to say
this worked, but that didn't?
Any suggestions or wisdom welcomed, or any guidelines buried in the
history of Hamlib.
73
n3gb
|
|
From: Black M. <mdb...@ya...> - 2024-09-10 21:28:11
|
You can look at ic7300.c for ic7300_set_clock.
I didn't bother to try and figure out too much and just set based on whatever gets passed in but only gets set if hour >= 0.
Command will likely fail if bogus data is sent.
In rigctl I allow this:
set_clock 'DateTime'
Set 'DateTime'
Sets rig clock -- note that some rigs do not handle seconds or milliseconds. If you try to set sec/msec and rig does
not support it you will get a debug warning message. Format is ISO8601,
Formats accepted allow for 2-digit or 4-digit time zone
YYYY-MM-DDTHH:MM:SS.SSS+ZZ (where +ZZ is either -/+ UTC offset HH)
YYYY-MM-DDTHH:MM:SS.SSS+ZZZZ (where +ZZZZ is either -/+ UTC offset HHMM)
YYYY-MM-DDTHH:MM:SS+ZZ
YYYY-MM-DDTHH:MM:SS+ZZZZ
YYYY-MM-DDTHH:MM+ZZ
YYYY-MM-DDTHH:MM+ZZZZ
YYYY-MM-DD (sets date only)
local (sets both clocks to local time)
utc (sets both clocks to utc time)
Note: Icom rigs expect you to set local time and the hours off to UTC.
So...4PM EST example would be 2021-12-01T16:00:00+0500
But...if you want to display GMT you must set the clock for GMT with zero UTC offset.
Hopefully Icom will allow displaying either clock in the future
On Tuesday, September 10, 2024 at 03:41:30 PM CDT, George Baltz <geo...@gm...> wrote:
I have been working on implementing rig_{get|set}_clock for the Kenwood
TS-890S/990S and need some advice on handling a quirk in the way the
clock interacts with other functions.
The rigs each have two clocks, called the local clock and auxiliary
clock (or secondary.) Common practice is to set the local clock to
local time and the aux to UTC. Only the local clock is directly
settable; it looks like the rig subtracts the local TZ offset to find
UTC, then uses the aux offset (in this case zero) to set the aux. Both
offsets are settable.
The two rigs are network-capable, and when connected they have the
option to sync the base clock(UTC) via NTP. When this is enabled the
clock setting function is disabled, both by CAT and the menu system;
only the offsets can be changed.
The problem I have is what to do with the single rig_set_clock() call.
I can't set the clock, but I'd like to set the offset (at least twice a
year). Do I just fail the whole thing? Do I ignore the clock if all of
YMDhms = 0? Set the offset first and bail if clock setting is
disabled? And what kind of result/status do I report? Any way to say
this worked, but that didn't?
Any suggestions or wisdom welcomed, or any guidelines buried in the
history of Hamlib.
73
n3gb
_______________________________________________
Hamlib-developer mailing list
Ham...@li...
https://lists.sourceforge.net/lists/listinfo/hamlib-developer
|
|
From: George B. <geo...@gm...> - 2024-09-14 18:49:44
|
On 9/10/24 5:27 PM, Black Michael wrote:
> You can look at ic7300.c for ic7300_set_clock.
> I didn't bother to try and figure out too much and just set based on whatever gets passed in but only gets set if hour >= 0.
> Command will likely fail if bogus data is sent.
Thanks for the pointer. I had looked through icom.c and newcat.c and
found nothing. Should've done a full grep.
I wish I had the flexibility to set either time or date but that's one
big command; at least the offset is separate. What I will probably do
is to set the offset first, then the time&date. That way if the time is
locked onto NTP, I can bail and the TZ will still be set to what the app
wanted. It still bothers me to give a RIG_OK when something couldn't be
accomplished, but I don't see any way to report partial success.
>
> In rigctl I allow this:
>
> set_clock 'DateTime'
> Set 'DateTime'
>
>
> Sets rig clock -- note that some rigs do not handle seconds or milliseconds. If you try to set sec/msec and rig does
> not support it you will get a debug warning message. Format is ISO8601,
> Formats accepted allow for 2-digit or 4-digit time zone
> YYYY-MM-DDTHH:MM:SS.SSS+ZZ (where +ZZ is either -/+ UTC offset HH)
> YYYY-MM-DDTHH:MM:SS.SSS+ZZZZ (where +ZZZZ is either -/+ UTC offset HHMM)
> YYYY-MM-DDTHH:MM:SS+ZZ
> YYYY-MM-DDTHH:MM:SS+ZZZZ
> YYYY-MM-DDTHH:MM+ZZ
> YYYY-MM-DDTHH:MM+ZZZZ
> YYYY-MM-DD (sets date only)
> local (sets both clocks to local time)
> utc (sets both clocks to utc time)
> Note: Icom rigs expect you to set local time and the hours off to UTC.
> So...4PM EST example would be 2021-12-01T16:00:00+0500
> But...if you want to display GMT you must set the clock for GMT with zero UTC offset.
> Hopefully Icom will allow displaying either clock in the future
EST is -0500. Will fix when I add the Kenwood notes.
>
>
>
>
>
>
>
>
>
>
> On Tuesday, September 10, 2024 at 03:41:30 PM CDT, George Baltz <geo...@gm...> wrote:
>
>
>
>
>
> I have been working on implementing rig_{get|set}_clock for the Kenwood
> TS-890S/990S and need some advice on handling a quirk in the way the
> clock interacts with other functions.
>
> The rigs each have two clocks, called the local clock and auxiliary
> clock (or secondary.) Common practice is to set the local clock to
> local time and the aux to UTC. Only the local clock is directly
> settable; it looks like the rig subtracts the local TZ offset to find
> UTC, then uses the aux offset (in this case zero) to set the aux. Both
> offsets are settable.
>
> The two rigs are network-capable, and when connected they have the
> option to sync the base clock(UTC) via NTP. When this is enabled the
> clock setting function is disabled, both by CAT and the menu system;
> only the offsets can be changed.
>
> The problem I have is what to do with the single rig_set_clock() call.
> I can't set the clock, but I'd like to set the offset (at least twice a
> year). Do I just fail the whole thing? Do I ignore the clock if all of
> YMDhms = 0? Set the offset first and bail if clock setting is
> disabled? And what kind of result/status do I report? Any way to say
> this worked, but that didn't?
>
> Any suggestions or wisdom welcomed, or any guidelines buried in the
> history of Hamlib.
>
>
> 73
>
> n3gb
>
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
|
|
From: Black M. <mdb...@ya...> - 2024-09-14 19:57:43
|
Maybe we can define two constants
#define RIG_CLOCK_UTC -1
#define RIG_CLOCK_LOCAL -2
Then in set_clock if you pass in those for the utc_offset you get utc or local time set respectively.
Either that or we make another set_clock call.
Thoughts? Once that's done I can probably get Uwe to add that to WSJT-X and make UTC the default to be overriden in hamlib_settings.json for LOCAL time.
Mike W9MDB
On Saturday, September 14, 2024 at 01:49:34 PM CDT, George Baltz <geo...@gm...> wrote:
On 9/10/24 5:27 PM, Black Michael wrote:
> You can look at ic7300.c for ic7300_set_clock.
> I didn't bother to try and figure out too much and just set based on whatever gets passed in but only gets set if hour >= 0.
> Command will likely fail if bogus data is sent.
Thanks for the pointer. I had looked through icom.c and newcat.c and
found nothing. Should've done a full grep.
I wish I had the flexibility to set either time or date but that's one
big command; at least the offset is separate. What I will probably do
is to set the offset first, then the time&date. That way if the time is
locked onto NTP, I can bail and the TZ will still be set to what the app
wanted. It still bothers me to give a RIG_OK when something couldn't be
accomplished, but I don't see any way to report partial success.
>
> In rigctl I allow this:
>
> set_clock 'DateTime'
> Set 'DateTime'
>
>
> Sets rig clock -- note that some rigs do not handle seconds or milliseconds. If you try to set sec/msec and rig does
> not support it you will get a debug warning message. Format is ISO8601,
> Formats accepted allow for 2-digit or 4-digit time zone
> YYYY-MM-DDTHH:MM:SS.SSS+ZZ (where +ZZ is either -/+ UTC offset HH)
> YYYY-MM-DDTHH:MM:SS.SSS+ZZZZ (where +ZZZZ is either -/+ UTC offset HHMM)
> YYYY-MM-DDTHH:MM:SS+ZZ
> YYYY-MM-DDTHH:MM:SS+ZZZZ
> YYYY-MM-DDTHH:MM+ZZ
> YYYY-MM-DDTHH:MM+ZZZZ
> YYYY-MM-DD (sets date only)
> local (sets both clocks to local time)
> utc (sets both clocks to utc time)
> Note: Icom rigs expect you to set local time and the hours off to UTC.
> So...4PM EST example would be 2021-12-01T16:00:00+0500
> But...if you want to display GMT you must set the clock for GMT with zero UTC offset.
> Hopefully Icom will allow displaying either clock in the future
EST is -0500. Will fix when I add the Kenwood notes.
>
>
>
>
>
>
>
>
>
>
> On Tuesday, September 10, 2024 at 03:41:30 PM CDT, George Baltz <geo...@gm...> wrote:
>
>
>
>
>
> I have been working on implementing rig_{get|set}_clock for the Kenwood
> TS-890S/990S and need some advice on handling a quirk in the way the
> clock interacts with other functions.
>
> The rigs each have two clocks, called the local clock and auxiliary
> clock (or secondary.) Common practice is to set the local clock to
> local time and the aux to UTC. Only the local clock is directly
> settable; it looks like the rig subtracts the local TZ offset to find
> UTC, then uses the aux offset (in this case zero) to set the aux. Both
> offsets are settable.
>
> The two rigs are network-capable, and when connected they have the
> option to sync the base clock(UTC) via NTP. When this is enabled the
> clock setting function is disabled, both by CAT and the menu system;
> only the offsets can be changed.
>
> The problem I have is what to do with the single rig_set_clock() call.
> I can't set the clock, but I'd like to set the offset (at least twice a
> year). Do I just fail the whole thing? Do I ignore the clock if all of
> YMDhms = 0? Set the offset first and bail if clock setting is
> disabled? And what kind of result/status do I report? Any way to say
> this worked, but that didn't?
>
> Any suggestions or wisdom welcomed, or any guidelines buried in the
> history of Hamlib.
>
>
> 73
>
> n3gb
>
>
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X