Re: [Dgtnix-devel] DGT Clock handling

[Alexander W. <a.w...@ph...>]

Pierre Boulenguez wrote:

Hello Pierre!

Nice to hear from you again! :) Admitting that I've ben just
to busy for "professional" reasons, and thus a bit silent
myself for quite a while.

> Indeed sending a string to the clock is not implemented
> yet.

Noticed that :) Now that I've the possibility to play
arround with a clock it came to my mind to try.

But besides sending a string like "Nf3" to the clock, it
would IMHO be of much greater value if one could use "Mode
23", that is set the timing on the clock by an external
source. This would be very handy for playing on FICS e.g.
where Scid makes a pretty good client these days and it
could also come in handy for the playing functionality that
got added to Scid recently as well. However, for the latter
I'm about to add also the inverse, ie. that the external
clock can be used to set Scids internal game clocks, as the
DGT clock offers much more flexibility today than Scids
timing functions.

> Regarding the clock, do you mean that when the clock is
> pluged to the board but the power switch is turned off,
> dgtnix returns 'not present' ?  If so, it's not a bug,
> just a lack of documentation.

No. If I plug to clock to the board, turn it on but not yet
start it, it reports "not present". That is the clock is
there but just halted. That is everything is ready for a
match. The point is not entirely catastrophic as I get a
time event once the clock starts running, but it takes me
the possibility to present a nice button to the user "Use
external time source" which I could disable if no clock is
found.

However, it gets critical once I could use Mode 23, cause
then I'd have to set one time reference.

Ah, and I also noticed a slight inconvenience while handling
the board descriptor. As both, the clock and the move events
come in on the same descriptor, a half move however consists
of two board events (remove piece and place piece) I usually
see at least one clock event between the two events for a
move, simply cause the clock event comes in every second at
the least.  This gets even worse for casteling, where a
single ply consists of 4 board events. It took me a while to
fiddle all these incoming events apart without deadlocking
the move recognigion. Things would IMHO be easier if the
clock events would come in via a separate descriptor, or the
clock would not generate any events on the descriptor but
move the time information dgtnixGetClockData(). The API is a
bit inconsistent here (IMHO), as there is actually no need
to see the bare clock events as there is a nice function
that delivers them in usable form.

My first approach was to set the board to UPDATE_BRD instead
of UPDATE. Funny enough this got me the clock hooked of
entirely, though I tried to send a DGT_SEND_CLK before
invoking dgtnixGetClockData(). (BTW: there seems a function
missing that allows to send bare DGT commands to the board.)
I was a bit confused here and then resorted back to fiddling
appart the both event types in my own code.

BTW: The clock I've here is version 1.14, according to the
imprints, my boards electronics is 1.9.

-- 

Kind regards,                /                 War is Peace.
                             |            Freedom is Slavery.
Alexander Wagner            |         Ignorance is Strength.
                             |
                             | Theory     : G. Orwell, "1984"
                            /  In practice:   USA, since 2001