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
[Tlf-devel] Autosend feature
Was: Re: [Tlf-devel] WAEDC QTC - v0.002 release :) --- Dne 3.11.2013 22:09, Fred Siegmund napsal(a): 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 Hi Fred, the Autosend feature is that which is in TRlog activated with AUTO CALL TERMINATE = TRUE AUTO SEND CHARACTER COUNT = 4 (here the autosend starts at 4th character). Better is an example: OK1RRA comes back to your CQ and you want to reply. So you type OK1R (4 characters) and your program begins to send. You are now in a hurry (a bit :-) because you must complete typing the whole call till the sending procedure catches you, here you must add RA. Then follows the exchange, the first ENTER logs in the QSO. Some OPs hate this option, some (me including) are in love with this. Except typing the call, you need only a single ENTER to make a complete QSO. Isn't nice such option? Also, many other progs have this feature... Of course, I make thorough tests of any TRLOGLinux version but it is still far away from an useful program. Many poor bottlenecks inherited from the obsolete DOS version - not only the impossibility to edit the complete log but the telnet operations, the hardcoded (thus very limited) support of quite few radio models, the predefined exchange types (an obvious quirk when the program tries to think for the operator) and much more. Anyway, TRlog (the original DOS version) introduced a new philosophy which is still unbeaten today. tlf should get much inspiration here. QTC handling in WAE is an example... CW/SSB contesters here know all the tricks of N1MM, TR4W, WriteLog and other powerful software packages used by winners. I believe that tlf should come close to these top runners. First if meets all requirements of top grade CW/SSB contesters, we should start with digimodes. Now (it seems at least to me) is too early, there is a danger that we will have an universal multimode program which does all, but does all quite bad, with many unnecessary typing etc. which can make a program useless for a tired operator, who is in a contest for whole weekend. Anyway, I am very happy with tlf. This is the reason of my support of this software (TRLOGLinux and so2sdr being still ignored here...). Kudos to all authors and contributors, also my apologies that I am not a coder, I am just operator who can make some tests and suggest and old, forgotten feature. 73, Martin, OK1RR ___ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
Re: [Tlf-devel] TLF RTTY with Fldigi
Hello Ed, On Mon, Nov 04, 2013 at 01:36:28PM -0500, Ed wrote: I used some of Fred's post from 2012 and came up with the following: If you want to use tlf in a RTTY contest with fldigi. Add this to the logcfg.dat: RTTYMODE GMFSK=/home/youruser/gMFSK.log DIGIMODEM=/home/youruser/gmfsk_autofile Create a file in /home/youruser named: TLFfldigi and one named gMFSK.log and one named gmfsk_autofile In tlf you need to open the miniterm: :mini thanks for above, I tested this using the CQ WW as a testbed. Worked perfectly. I also went back to 2006 and read through some of Rein's post about using gMFSK. Without the special version of gMFSK that Rein used, I'm afraid using another verson may not work. that's the main problem: I don't find anywhere that patch(set), so gMFSK is unusable. ==snip== At this moment I'm tryin the Fldigi, and looks like that works with same settings like you described above (doh! - fldigi uses gmfsk* prefix... why?) I think I can start to test the QTC send and receive implementation. thanks for your help :), 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] Autosend feature
Ok, interesting indeed. The functionality is basicly there, but broken. I always wondered what such a important key like space does in TRLOG mode. Well, it just doesn't work like intended (arrow down is the same). The same is true for the :char command (autosend). See the original meaning: http://pa0r.blogspirit.com/archive/2005/03/29/autostart_cw_for_tlf.html I think its a bug. ;-) 73 Fred On 11/04/2013 07:39 PM, Martin Kratoska wrote: Was: Re: [Tlf-devel] WAEDC QTC - v0.002 release :) --- Dne 3.11.2013 22:09, Fred Siegmund napsal(a): 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 Hi Fred, the Autosend feature is that which is in TRlog activated with AUTO CALL TERMINATE = TRUE AUTO SEND CHARACTER COUNT = 4 (here the autosend starts at 4th character). Better is an example: OK1RRA comes back to your CQ and you want to reply. So you type OK1R (4 characters) and your program begins to send. You are now in a hurry (a bit :-) because you must complete typing the whole call till the sending procedure catches you, here you must add RA. Then follows the exchange, the first ENTER logs in the QSO. Some OPs hate this option, some (me including) are in love with this. Except typing the call, you need only a single ENTER to make a complete QSO. Isn't nice such option? Also, many other progs have this feature... Of course, I make thorough tests of any TRLOGLinux version but it is still far away from an useful program. Many poor bottlenecks inherited from the obsolete DOS version - not only the impossibility to edit the complete log but the telnet operations, the hardcoded (thus very limited) support of quite few radio models, the predefined exchange types (an obvious quirk when the program tries to think for the operator) and much more. Anyway, TRlog (the original DOS version) introduced a new philosophy which is still unbeaten today. tlf should get much inspiration here. QTC handling in WAE is an example... CW/SSB contesters here know all the tricks of N1MM, TR4W, WriteLog and other powerful software packages used by winners. I believe that tlf should come close to these top runners. First if meets all requirements of top grade CW/SSB contesters, we should start with digimodes. Now (it seems at least to me) is too early, there is a danger that we will have an universal multimode program which does all, but does all quite bad, with many unnecessary typing etc. which can make a program useless for a tired operator, who is in a contest for whole weekend. Anyway, I am very happy with tlf. This is the reason of my support of this software (TRLOGLinux and so2sdr being still ignored here...). Kudos to all authors and contributors, also my apologies that I am not a coder, I am just operator who can make some tests and suggest and old, forgotten feature. 73, Martin, OK1RR ___ 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
