Re: [Hamlib-developer] How to handle partial functions?

[Black M. <mdb...@ya...>]

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