Re: [Tlf-devel] WAEDC QTC - v0.002 release :)
Yes, that could work. Lets say, the user enters the the series number like xx/xx, and the QRV message is sent, TLF is triggered to take everyting in a pattern like, by grabing it from gMFSK.log: cc nnn time call number I a not aware if they send in RTTY shortend versions, like two figures for the time, or so. Maybe the user could be asked if he wants to accept it, if yes a ROGER is send otherwise a PSE REPEAT. 73 Fred On 11/02/2013 01:36 PM, Ervin Hegedüs - HA2OS wrote: Hello, On Sat, Nov 02, 2013 at 01:40:27PM +0100, FS wrote: The biggest challenge is the reciving side. For CW you have to type it anyway, maybe that could be a intermediate solution. CW (and phone) is clear, and no problem - I think I can handle the fast speed CW too, and can type all data of QTC. But the RTTY is a littlebit faster :) But it would be nicer for RTTY to mark a complete line in miniterm (which is available in TLF), push a key combination and have it in the QTC box. Any solution within a different programme like fldigi, will be no short term solution and probably solved if the connection between this two programms is reworked. So for now a mouse integration for marking a line in miniterm seem to be the way - although not perfect. ;-) yes, the using miniterm should be the cleanest way, independent from anything. But the mouse integration would be hard work at this time, and (IMHO) Tlf should lost the magic feeling :) If Tlf reads from RTTY client log, maybe I could make a pattern, which recognize the first line of QTC block (NUMBER / NUMBER NEWLINE), and when the next lines contains the QTC pattern, it filled the QTC lines in receive window. Any idea? Thanks, 73: Ervin HA2OS 73 Fred Am 01.11.2013 21:55, schrieb Ervin Hegedüs - HA2OS: Dear HAM's, I still had not enough time as I expected to made the QTC patch, but here is the next release - please look at that. The send directions doesn't contains relevant changes. There is the another directions, the receive of QTC's. See, how it's works. If you press ALT+r when you are in exchange field (in current QSO line), the new window opens. In that window the 1st line has 2 fields: the QTC block serial and number of QTC's. After this there are 10 empty lines, every lines has 3 block, as QTC: time (HHMM), callsign, and serial. If you put the serial and number of QTC's, the left side of 1st columns will appears the numbers, to help to the operators to see, which rows are affected. You can move the cursor between the fields with TAB and SHIFT+TAB (backward direction), and UP/DOWN cursor move keys. In a field, you can use BACKSPACE, DELETE, and LEFT/RIGHT cursor move keys to move the cursor, and real contains of fields. In time and serial fields, you can type only numbers, and ? (question-mark). In callsign field, you can type letters, numbers, '/' and '?' signs. If a QTC line contains a '?' sign at anywhere, you can see a '?' sign at end of the line - that means, you've marked this QTC as incomplete. In CW mode (in future) Tlf doesn't will send 'R' sign, instead it send 'AGN #', where # will the number of QTC. If you type 'ESC', the QTC window will hide, but when again type ALT+r, the filled window will open again. If you change the callsign in QSO line (when QTC window is not showed), the contains of QTC will be deleted. Now, this is the current level of development. Further plans: - if all fields of a QTC (time, callsign, serial) is complete, and you type the ENTER, the QTC will be marked as complete, and this status will be indicated with an '*' (asterix) sign, the end of line - if you are in last QTC, and all QTC's are marked as completed, then after the pressing of ENTER, the window will be closed - if you save the QSO, and QTC window contains records, they will be saved with QSO (same as sending QTC) I think I can do these to the next weekend, when WAEDC RTTY will starts, but I never used QTC, and I don't know is it a good choice to handle the receive direction of that. To come out of this: - merge QTC's with QSO's in Cabrillo log - at send direction to handle the QTC's with an external program, eg. gMFSK - I think it's not too difficult - at receive direction to handle the QTC's; I mean, it would be a good choice to implement a feature in RTTY software, when the operator select a TEXT in receive window, and (eg.) with right click it could be send the selected text as QTC to Tlf; in this case, the Tlf must to handle the new logtype through LAN If anybody has a good idea one of those contexts above, please send me an e-mail through this list or direct. Of course, to check the Tlf, you need the git, gcc, and make tools. The repository of this patched version is this: https://github.com/airween/tlf/tree/waedc-qtc 73: Ervin HA2OS ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] WAEDC QTC - v0.002 release :)
The file is still called gMFSK.log. What goes to FLDIGI is written to a file called TLFfldigi. That works pretty well, Thomas did some updates on the original code, eg.fixing the LF problem in the TX direction. 73 Fred On 11/02/2013 01:48 PM, Ervin Hegedüs - HA2OS wrote: Hello Ed, On Sat, Nov 02, 2013 at 09:15:36AM -0400, Ed wrote: On Sat, 02 Nov 2013 13:40:27 +0100 FS dh...@freenet.de wrote: The biggest challenge is the reciving side. For CW you have to type it anyway, maybe that could be a intermediate solution. But it would be nicer for RTTY to mark a complete line in miniterm (which is available in TLF), push a key combination and have it in the QTC box. Any solution within a different programme like fldigi, will be no short term solution and probably solved if the connection between this two programms is reworked. So for now a mouse integration for marking a line in miniterm seem to be the way - although not perfect. ;-) 73 Fred The problem with miniterm is excessive LFs', especially using fldigi. may be that's no problem, I could modify the source, if Tlf detects the QTC block, it doesn't skip LF - or, in this case, the result is showed in QTC rec window, instead of miniterm. And gMFSK is old and no longer maintained and may not be adequate. hmm... that's a very important news for me. Usually I work in digimodes just sometimes, and then I use gMFSK. In September of this year, I did the CQ WW DX RTTY, this was my first digimode contest. I realize the deficiency of gMFSK, and then started to make the Tlf patch. I didn't use Fldigi anytime, yesterday I've started to explore that. The send direction is works for me (through gmfsk_autofile), but I couldn't conigure the receive direction, so I didn't find the equivalent with gMFSK.log, and what Fldigi receives, that isn't seems in Tlf miniterm. How can I configure it? Thanks, 73: Ervin HA2OS Ed W3NR ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] WAEDC QTC - v0.002 release :)
Hello Fred, On Sun, Nov 03, 2013 at 09:09:00AM +, FS wrote: The file is still called gMFSK.log. What goes to FLDIGI is written to a file called TLFfldigi. That works pretty well, Thomas did some updates on the original code, eg.fixing the LF problem in the TX direction. thanks for your reply, so, I don't understand really the accureate mechanism - now I'm working on my laptop, I can't check the Fldigi. Afternoon I will try to find that log, and setting up Tlf to work with Fldigi for both directions. 73, Ervin HA2OS -- I � UTF-8 ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] WAEDC QTC - v0.002 release :)
hello, On Sun, Nov 03, 2013 at 09:04:26AM +, FS wrote: Yes, that could work. Lets say, the user enters the the series number like xx/xx, and the QRV message is sent, TLF is triggered to take everyting in a pattern like, by grabing it from gMFSK.log: cc nnn time call number Till I looked the examples of QTC, especially RTTY mode, I found this (very good) summary: http://www.guernsey.net/~pcooper/waedc.html On this page the author said there are several forms of QTC: So, you will end up with something like this: 001/10 0012 G3URA 049 0013/AA5AU/056 0014-RA9FOE-012 etc for ten lines. So, the separator sign should be (space), / (slash), - (hyphen/minus) character. That's no problem, but it would be nice to know, is there any other formula to separate the fields, or operators (and softares) only uses these? I think I can handle all or them above. I a not aware if they send in RTTY shortend versions, like two figures for the time, or so. I don't know that too... :) Maybe the user could be asked if he wants to accept it, if yes a ROGER is send otherwise a PSE REPEAT. Hmmm... I'm not sure is it a good solution. Otherwise, if somebody had WAEDC-RTTY, and received many QTC's, please confirm that: anybody (or any software) uses the different formula that listed above, or not? thanks, 73: Ervin HA2OS -- I � UTF-8 ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] WAEDC QTC - v0.002 release :)
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. - The excessive LF's should be gone in the tlf-1.2.0pre series. - 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. - 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. 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. 73, Tom DL1JBE. -- Do what is needful! Ursula LeGuin: Earthsea -- ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] WAEDC QTC - v0.002 release :)
Hi all, with highest respect to all the work already done, I suggest to focus all our potential to CW and SSB modes and the usual options to get *finally* an useful, mature contesting program for Linux. tlf still has some bottlenecks, in many contests is possible to enter the event but scoring does not work properly, missing the autosend option (in the same way as TRlog N6TR does), spotting is a pain etc. The quality of a program strongly depends on the ergonomics - the typing should be minimized as well as the keyboard schedule should single stroke commands (ie. no Ctrl- or Alt- keys) etc. If applicable, I will summarize all my suggestions and send to the forum. 73, Martin, OK1RR - The activation of tlf's digimode ... ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] correction
... as the keyboard schedule should single stroke commands (ie. no Ctrl- or Alt- keys) etc. should be ... as the keyboard schedule should use single stroke commands instead of written text commands, also possibly no Ctrl- or Alt- keys etc. My apologies, TNX Martin, OK1RR ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] WAEDC QTC - v0.002 release :)
Hi Martin, which autosend feature do you mean? I worked with TRLOGLinux and was not very satisfied, namely the bandmap is very slow and there some inherited things from the original program that are very stupid. Like its not possible to edit the complete log. These are points were a distinct progression from TRLog is visible (already developed by Rein). 73 Fred Am 03.11.2013 19:40, schrieb Martin Kratoska: Hi all, with highest respect to all the work already done, I suggest to focus all our potential to CW and SSB modes and the usual options to get *finally* an useful, mature contesting program for Linux. tlf still has some bottlenecks, in many contests is possible to enter the event but scoring does not work properly, missing the autosend option (in the same way as TRlog N6TR does), spotting is a pain etc. The quality of a program strongly depends on the ergonomics - the typing should be minimized as well as the keyboard schedule should single stroke commands (ie. no Ctrl- or Alt- keys) etc. If applicable, I will summarize all my suggestions and send to the forum. 73, Martin, OK1RR - The activation of tlf's digimode ... ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
