Re: [Tlf-devel] WAEDC QTC - v0.002 release :)
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. ___ 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:55:51PM +0100, Fred Siegmund wrote: Ok, there seems to be one significant difference to CW/SSB. The QTCs in RTTY are transmitted in batches. yes, that's the challenge :) Till I made all of the WAEDC modifications (first patch was only the correct handling of points and multipliers), I've tried to keep in mind this difference. Eg: in CW/SSB modes, QSO's allowed only in EU-DX relation, but in RTTY every station should work with from anywhere. In CW/SSB modes, only the DX stations should send QTC to only the EU stations, in RTTY all station should send QTC to everyone, except same continent. And techically, in RTTY the QTC are sending in batch mode, instead of one by one. This makes it somehow difficult to keep it compatible, but its possible (different DIGIMODE handling). yes, and (I hope :)) my codes handles it correctly. There need to be a macro to request to repeat a selected line. Another macro for repeat all. When ALT-R is pressed TLF should be looking for a line begining with QTC xxx/xx to have a trigger point. And then copy the whole block in. I found out that if a line contains '?', that will be signed as incomplete - this is the macro. Then if you press ENTER, Tlf will send PSE RPT #N immediately (!). If all lines are marked as complete (simply press ENTER, and line doesn't contain '?'), and then press ENTER, Tlf will send 'TNX QTC NNN/NN' or any other message, and close the window. This method can work only in RTTY, but the different from CW/SSB is not so much: in that modes, if you marked a QTC as complete, the 'R' signal will send immediately, not after if you get all QTC's. Hope this should be usable, but if you have any idea, please let me know. 73, Ervin HA2OS 73 Fred Am 03.11.2013 10:49, schrieb Ervin Hegedüs - HA2OS: 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 ___ 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 :)
Yes, that sound good. I am only a little bit afraid of garbage while decoding (because of weak signals). But thats also a question how good the squelch is set. 73 Fred On 11/04/2013 09:09 AM, Ervin Hegedüs wrote: Hello Fred, On Sun, Nov 03, 2013 at 09:55:51PM +0100, Fred Siegmund wrote: Ok, there seems to be one significant difference to CW/SSB. The QTCs in RTTY are transmitted in batches. yes, that's the challenge :) Till I made all of the WAEDC modifications (first patch was only the correct handling of points and multipliers), I've tried to keep in mind this difference. Eg: in CW/SSB modes, QSO's allowed only in EU-DX relation, but in RTTY every station should work with from anywhere. In CW/SSB modes, only the DX stations should send QTC to only the EU stations, in RTTY all station should send QTC to everyone, except same continent. And techically, in RTTY the QTC are sending in batch mode, instead of one by one. This makes it somehow difficult to keep it compatible, but its possible (different DIGIMODE handling). yes, and (I hope :)) my codes handles it correctly. There need to be a macro to request to repeat a selected line. Another macro for repeat all. When ALT-R is pressed TLF should be looking for a line begining with QTC xxx/xx to have a trigger point. And then copy the whole block in. I found out that if a line contains '?', that will be signed as incomplete - this is the macro. Then if you press ENTER, Tlf will send PSE RPT #N immediately (!). If all lines are marked as complete (simply press ENTER, and line doesn't contain '?'), and then press ENTER, Tlf will send 'TNX QTC NNN/NN' or any other message, and close the window. This method can work only in RTTY, but the different from CW/SSB is not so much: in that modes, if you marked a QTC as complete, the 'R' signal will send immediately, not after if you get all QTC's. Hope this should be usable, but if you have any idea, please let me know. 73, Ervin HA2OS 73 Fred Am 03.11.2013 10:49, schrieb Ervin Hegedüs - HA2OS: 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 ___ 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 Mon, Nov 04, 2013 at 10:51:44AM +, FS wrote: Yes, that sound good. I am only a little bit afraid of garbage while decoding (because of weak signals). But thats also a question how good the squelch is set. yes, I tried to think that, and for this reason I choosed this method, what I described. I think there isn't any way to full automatization to receive the QTC - like we couldn't catch the callsign and/or RST and serial. 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 :)
Hi Ervin, Am Mon, 4 Nov 2013 09:48:57 +0100 schrieb Ervin Hegedüs airw...@gmail.com: - 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? Help will be useful. But I fear implementation can only be done here in next 1..2 month. At the moment there is no urgent need for it, we can use the old GMFSK interface for now. But we should discuss that in a separate thread. 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. I can have a look into it near the end of the week. Luckily we need the Cabrillo formatting only after the contest for preparation of the final log. Main question is how you store the QTC send/receive information. With the new Cabrillo handling in place it should be not too difficult to extend it for the QTC's. 73, de 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 :)
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
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
Re: [Tlf-devel] WAEDC QTC - v0.002 release :)
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 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 :)
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. And gMFSK is old and no longer maintained and may not be adequate. Ed W3NR ___ 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 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 -- I � UTF-8 ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
[Tlf-devel] WAEDC QTC - v0.002 release :)
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 -- I � UTF-8 ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
