Re: [Tlf-devel] WAEDC QTC - v0.002 release :)

[Ervin Hegedüs]

Hello everyone :),

On Sun, Nov 03, 2013 at 05:44:09PM +0100, Thomas Beierlein wrote:
> Hi Ervin, Fred and Ed,
> 
> I was away some days, but let me add my 2 ct's to the discussion.
> 
> - The activation of tlf's digimode got explained last by Fred in his
> post from 26 Sep 2012 (should be still in the archive). Besides the
> mentioned entries for logcfg.dat you need to activate the miniterm
> window with ':miniterm' from within tlf's callinput field.
> Maybe we should write a README.digi and add it to the distribution.

ok, but I think if somebody wants to use Tlf for RTTY, it can be
found the required infos on the net. Eg. I found it in Rein's
original post, about in 2005 or 2006.

> - The excessive LF's should be gone in the tlf-1.2.0pre series. 

ack,

> - I had planned to code a native fldigi interface in spring but as it
>   was a busy year here it is still on the todo list. I planned to add a
>   new FLDIGI keyword and use the socket interface for communication.
>   The old GMFSK mechanism will be gone in fldigi in some time.

what do think about this, when do you implement this socket
interface? Do you need any help?
 
> - Fred your idea with selecting the received QTC via mouse is nice but
>   at the moment there is little to no support for mouse recognition in
>   tlf. Main reason is the hard coded key handling in 'onechar.c'. I
>   have some experimental work here to switch to native ncurses keyboard
>   interface. That will allows us to add mouse handling to tlf. It is
>   nearly done but needs testing.

I agree this.

> As tlf-1.2.0 still needs some work I have backported at least the new
> cabrillo v3  handling to tlf 1.1.x series and will release 1.1.7 in
> next days.
> 
> For 1.2.0 to be ready I want to fix the following two problems first:
> 
> - The above mentioned FLDIGI interface for digimode.
> - A unified handling of scoring during QSO entry and reload of log
>   after startup. At the moment that are two different code path and
>   every change to one of them needs to be carefully balanced out on the
>   other way. I dropped already two or three times into that problem.
> 
> Maybe WAEDC handling is ready at that time too and we can add it to
> the new 1.2.0. 

Yesterday I've comitted the QTC's receive direction to WAEDC-QTC
branch. Here are the remaining tasks:
- in CW and DIGIMODES send messages; I mean, if operator wants to
  send QTC, Tlf could handle the full block. If operator receives
  QTC's, Tlf could send "ROGER" or "R", "RPT NN" or other
  messages.
  I think these aren't too big challanges.
- automatic receive of QTC
  That's a big question, how should we use that, and maybe it
  depends the DIGIMODE interface.
- merged QTC's with QSO's in Cabrillo

I have an idea, just start for the collective thinking: if other
station asks the 'QTC QRV?', and operator press ALT+r when the
current field is serial, Tlf opens the QTC receive window, and
send a 'QTC QRV' message. Thereafter looks the RTTY client
messages, and try to recognize the format of lines. If a line
matches with a predefined format, it will be handled accordingly.

I think it could be doing that in a new thread (posix thread),
which reads the RTTY client messages, handle it, and fill the
receive window fields. Till the operator can edit the fields if
required, and can mark the line with ENTER (*). Otherwise it will
be marked as complete. The status will be indicated in left to
the line. Please don't forget, the message sending is not
implemented!

I'm afraid I don't have enough time to finish to merge the QTC's
with QSO's in Cabrillo till WAEDC-RTTY contest (to this weekend),
if somebody could help me, I appreciate it :). First, I will
implement the message sending, then handling the receive of
QTC's.


Any remarks/ideas are welcomes :)


73,

Ervin
HA2OS


*: in receive mode if any field contains a '?' (question mark),
that line will be marked as incomplete. When you are in a kind of
this line, and pressing ENTER, then Tlf will send "PSE RPT NN".
The message sending is not implemented currently.