Re: Real RST possible?
Am Tue, 28 Jan 2020 16:47:05 -0600 schrieb jim smith : > On Tue, 28 Jan 2020 20:13:04 +0100 > Thomas Beierlein wrote: > > > Ok, That would only extend the functionality of CHANGE_RST. If > > changing only the first two numbers are enough that would be the > > most easy solution. If key auto repeat does also work for PgUp/PgDn > > (needs to be tested) you need not to much key presses to sweep over > > the range. > > > > Jim, would that solve your needs? If so it can be implemented in > > next weeks. > > I think so. And in any case, I think defer to "make it easiest for > the 'Run' operator. If the S op has to make a few more keypresses > to get things done, that's fine. Also, that final 9 can alwasy be 9 > in RST, IMO. OK, we will add it to the ToDO list then. > > > > Probably the reason this hasn't been requested before is that > > > major contest sponsors mostly ignore the signal report for log > > > checking. > > > > And in contest we ignore the 'real' RST value from the band and stay > > with 5nn to make more contacts per time. > > > > 73, de Tom > > I agree with that -- in most contests the RS(T) is a given. But for > QRP and especially SOTA operations (where I would *really* like to use > tlf), it would be most helpful to be able to type in the R and S of > RST. > > Thanks to all for considering this. I used tlf in last weekend's > CQ160m contest, and it never missed a beat. *I* did, but it did not. Good to hear :-). 73, de Tom -- "Do what is needful!" Ursula LeGuin: Earthsea --
Re: Real RST possible?
Am Tue, 28 Jan 2020 21:42:06 +0100 schrieb Csahok Zoltan : > > > Tap Page-Dn until '1' is reached and then like an odometer the > > > first numeral rolls down to '4', the next tap rolls the first > > > numeral down to '3' and so on while leaving the second numeral at > > > '1', then tap Page-Up to set the second numeral. That would > > > require a few taps of Page-Up until the report of 459 is reached. > > > > > Ok, That would only extend the functionality of CHANGE_RST. If > > changing only the first two numbers are enough that would be the > > most easy solution. If key auto repeat does also work for PgUp/PgDn > > (needs to be tested) you need not to much key presses to sweep over > > the range. > > One option could be to let the user configure the preferred reports > (say 599,559,339) and PgUp/Dn would cycle through them. > This would save a bunch of keystrokes for a user not needing too > precise RST. Sounds good. So a possible scheme could be: CHANGE_RST cycle through all values 599, 589, ..., 539, 499, .., 439, 399, .., 339 or CHANGE_RST=599, 559, 339 to cycle through the named RST values. > > The sequential rolling with PgUp/Dn is not too practical when it comes > to give someone 338. My feeling is that with a handful configured > reports one could effectively cover the requirement for sent RST. > Right. > For received RST direct entry would be better. But that could be done > with a wider exchange field. Maybe we should start with using CHANGE_RST here also and add additional the possibility for a direct change via the comment field if needed. One idea is to allow a 'r579' or similar in the comment field to override the received RST. 'r' makes clear that is it no exchange, accepts it and clears the comment field afterwards. That way we avoid the need to navigate between RST and real comment in the extended comment field. 73, de Tom -- "Do what is needful!" Ursula LeGuin: Earthsea --
Re: Real RST possible?
On Tue, 28 Jan 2020 20:13:04 +0100 Thomas Beierlein wrote: > Ok, That would only extend the functionality of CHANGE_RST. If > changing only the first two numbers are enough that would be the most > easy solution. If key auto repeat does also work for PgUp/PgDn (needs > to be tested) you need not to much key presses to sweep over the > range. > > Jim, would that solve your needs? If so it can be implemented in next > weeks. I think so. And in any case, I think defer to "make it easiest for the 'Run' operator. If the S op has to make a few more keypresses to get things done, that's fine. Also, that final 9 can alwasy be 9 in RST, IMO. > > Probably the reason this hasn't been requested before is that major > > contest sponsors mostly ignore the signal report for log checking. > > And in contest we ignore the 'real' RST value from the band and stay > with 5nn to make more contacts per time. > > 73, de Tom I agree with that -- in most contests the RS(T) is a given. But for QRP and especially SOTA operations (where I would *really* like to use tlf), it would be most helpful to be able to type in the R and S of RST. Thanks to all for considering this. I used tlf in last weekend's CQ160m contest, and it never missed a beat. *I* did, but it did not. 73, Jim KK0U
Re: Real RST possible?
> > Tap Page-Dn until '1' is reached and then like an odometer the first > > numeral rolls down to '4', the next tap rolls the first numeral down > > to '3' and so on while leaving the second numeral at '1', then tap > > Page-Up to set the second numeral. That would require a few taps of > > Page-Up until the report of 459 is reached. > > > Ok, That would only extend the functionality of CHANGE_RST. If changing > only the first two numbers are enough that would be the most easy > solution. If key auto repeat does also work for PgUp/PgDn (needs to be > tested) you need not to much key presses to sweep over the range. One option could be to let the user configure the preferred reports (say 599,559,339) and PgUp/Dn would cycle through them. This would save a bunch of keystrokes for a user not needing too precise RST. The sequential rolling with PgUp/Dn is not too practical when it comes to give someone 338. My feeling is that with a handful configured reports one could effectively cover the requirement for sent RST. For received RST direct entry would be better. But that could be done with a wider exchange field. 73, Zoli
Re: Real RST possible?
Am Tue, 28 Jan 2020 07:55:47 -0600 schrieb Nate Bargmann : > * On 2020 28 Jan 00:29 -0600, Thomas Beierlein wrote: > > Hi Jim, Nate and Zoli, > > > > we should keep in mind to integrate it in the flow of the qso, > > especially in contests. > > > > What I mean is running in CQ mode I need the RST of the other > > station *before* answering his call and will get his RST in his > > reply. Running in S I would first get my RST from him and only > > *afterwards* need his RST for my reply. > > > > Another question is if the operator uses ESM or not. > > To be honest, Tom, I don't see the way I described changing the > behavior of Enter or Space. It would merely modify the RST fields to > be entry boxes but would be prepopulated with 59[9] as now and Enter > and Space would skip them. Tab would move into each in turn from > Call --> RX RST --> TX RST --> Exchange --> Call (CQWW example). You are right. There are some chances in changing the handling of input fields, but to be honest it would be quite difficult. Reason is that the code to pick up the call sign and exchange is quite a tangled mess consisting of three main functions: callinput(), getexchange() and logit() - the last one tying all different modes (S, CQ, dxped and Qso mode) together. Before we sort that out it would be difficult to make major changes. > Your musing of Run vs S is a good one. For the most part, I think > this is a rather specific use case where the '5' is to be replaced by > another numeral. Most of us probably won't use this feature. ;-) > > Another option is to leave all keys as-is and only modify > Page-Up/Page-Dn so that they work this way: > > Tap Page-Dn until '1' is reached and then like an odometer the first > numeral rolls down to '4', the next tap rolls the first numeral down > to '3' and so on while leaving the second numeral at '1', then tap > Page-Up to set the second numeral. That would require a few taps of > Page-Up until the report of 459 is reached. > Ok, That would only extend the functionality of CHANGE_RST. If changing only the first two numbers are enough that would be the most easy solution. If key auto repeat does also work for PgUp/PgDn (needs to be tested) you need not to much key presses to sweep over the range. Jim, would that solve your needs? If so it can be implemented in next weeks. > Probably the reason this hasn't been requested before is that major > contest sponsors mostly ignore the signal report for log checking. And in contest we ignore the 'real' RST value from the band and stay with 5nn to make more contacts per time. 73, de Tom -- "Do what is needful!" Ursula LeGuin: Earthsea --
Re: Real RST possible?
* On 2020 28 Jan 00:29 -0600, Thomas Beierlein wrote: > Hi Jim, Nate and Zoli, > > we should keep in mind to integrate it in the flow of the qso, > especially in contests. > > What I mean is running in CQ mode I need the RST of the other > station *before* answering his call and will get his RST in his reply. > Running in S I would first get my RST from him and only *afterwards* > need his RST for my reply. > > Another question is if the operator uses ESM or not. To be honest, Tom, I don't see the way I described changing the behavior of Enter or Space. It would merely modify the RST fields to be entry boxes but would be prepopulated with 59[9] as now and Enter and Space would skip them. Tab would move into each in turn from Call --> RX RST --> TX RST --> Exchange --> Call (CQWW example). Your musing of Run vs S is a good one. For the most part, I think this is a rather specific use case where the '5' is to be replaced by another numeral. Most of us probably won't use this feature. ;-) Another option is to leave all keys as-is and only modify Page-Up/Page-Dn so that they work this way: Tap Page-Dn until '1' is reached and then like an odometer the first numeral rolls down to '4', the next tap rolls the first numeral down to '3' and so on while leaving the second numeral at '1', then tap Page-Up to set the second numeral. That would require a few taps of Page-Up until the report of 459 is reached. Probably the reason this hasn't been requested before is that major contest sponsors mostly ignore the signal report for log checking. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Real RST possible?
Hi Jim, Nate and Zoli, we should keep in mind to integrate it in the flow of the qso, especially in contests. What I mean is running in CQ mode I need the RST of the other station *before* answering his call and will get his RST in his reply. Running in S I would first get my RST from him and only *afterwards* need his RST for my reply. Another question is if the operator uses ESM or not. 73, Tom Am Mon, 27 Jan 2020 20:52:46 +0100 schrieb Csahok Zoltan : > Hi Nate, > > Everything is possible. :-) > > An option I see could be making the exchange box wider to span the > RST fields and let the user input the values. Optionally pre-fill > with 599/59. Then upon storing the qso we would parse the first 2 > words and store them as RSTs. > > A bit tedious for the user to fill and navigate within the exchange > field, but I assume these use cases are not focused on high Q rates. > > > 73, > Zoli > > > On Sun, Jan 26, 2020 at 06:26:36PM -0600, Nate Bargmann wrote: > > * On 2020 26 Jan 15:45 -0600, jim smith wrote: > > > First, I know there is the CHANGE_RST directive, but for QRP > > > contests (at least in the states), many times ops send an actual > > > RST -- 33N, 439, etc. Is there any way to incorporate this in > > > both the received stations data (I imagine it would be in the > > > exchange field, like a serial number) and for the sending > > > station? > > > > > > It would be helpful the above mentioned QRP contests, general > > > ragchews and for SOTA operations as well. > > > > I have seen other loggers handle this so that in the case of Tlf, > > Space would move the cursor from Call to the Exchange/Comment field > > and Tab would cycle through all fields, i.e., Call-->RX RST-->TX > > RST-->Exch-->Call, etc. > > > > As it is now, Space jumps from Call to Exch and then Tab must be > > used to go back to Call as Exch can contain spaces to separate > > exchange elements in some events. Loggers such as N1MM+ create > > additional field entry boxes depending on the event and Space is > > not allowed in any of them so it can be used as a "smart tab" that > > jumps over RST fields, if present, and through all the other fields. > > > > The way Tlf is structured, it would take a lot to have separate > > exchange fields, but it seems as though having Tab cycle through > > all the fields could be doable. As I see it, when Tab enters an > > RST field it could place the cursor under the first '9' and from > > there the field edited as needed. I'm afraid I don't have the time > > to code it for some months so maybe someone else can pick up the > > idea if it is thought to be a good one and add it. > > > > 73, Nate > > -- "Do what is needful!" Ursula LeGuin: Earthsea --
Re: Real RST possible?
Hi Nate, Everything is possible. :-) An option I see could be making the exchange box wider to span the RST fields and let the user input the values. Optionally pre-fill with 599/59. Then upon storing the qso we would parse the first 2 words and store them as RSTs. A bit tedious for the user to fill and navigate within the exchange field, but I assume these use cases are not focused on high Q rates. 73, Zoli On Sun, Jan 26, 2020 at 06:26:36PM -0600, Nate Bargmann wrote: > * On 2020 26 Jan 15:45 -0600, jim smith wrote: > > First, I know there is the CHANGE_RST directive, but for QRP contests > > (at least in the states), many times ops send an actual RST -- 33N, > > 439, etc. Is there any way to incorporate this in both the received > > stations data (I imagine it would be in the exchange field, like a > > serial number) and for the sending station? > > > > It would be helpful the above mentioned QRP contests, general ragchews > > and for SOTA operations as well. > > I have seen other loggers handle this so that in the case of Tlf, Space > would move the cursor from Call to the Exchange/Comment field and Tab > would cycle through all fields, i.e., Call-->RX RST-->TX > RST-->Exch-->Call, etc. > > As it is now, Space jumps from Call to Exch and then Tab must be used to > go back to Call as Exch can contain spaces to separate exchange elements > in some events. Loggers such as N1MM+ create additional field entry > boxes depending on the event and Space is not allowed in any of them so > it can be used as a "smart tab" that jumps over RST fields, if present, > and through all the other fields. > > The way Tlf is structured, it would take a lot to have separate exchange > fields, but it seems as though having Tab cycle through all the fields > could be doable. As I see it, when Tab enters an RST field it could > place the cursor under the first '9' and from there the field edited as > needed. I'm afraid I don't have the time to code it for some months so > maybe someone else can pick up the idea if it is thought to be a good > one and add it. > > 73, Nate >
Re: Real RST possible?
* On 2020 26 Jan 15:45 -0600, jim smith wrote: > First, I know there is the CHANGE_RST directive, but for QRP contests > (at least in the states), many times ops send an actual RST -- 33N, > 439, etc. Is there any way to incorporate this in both the received > stations data (I imagine it would be in the exchange field, like a > serial number) and for the sending station? > > It would be helpful the above mentioned QRP contests, general ragchews > and for SOTA operations as well. I have seen other loggers handle this so that in the case of Tlf, Space would move the cursor from Call to the Exchange/Comment field and Tab would cycle through all fields, i.e., Call-->RX RST-->TX RST-->Exch-->Call, etc. As it is now, Space jumps from Call to Exch and then Tab must be used to go back to Call as Exch can contain spaces to separate exchange elements in some events. Loggers such as N1MM+ create additional field entry boxes depending on the event and Space is not allowed in any of them so it can be used as a "smart tab" that jumps over RST fields, if present, and through all the other fields. The way Tlf is structured, it would take a lot to have separate exchange fields, but it seems as though having Tab cycle through all the fields could be doable. As I see it, when Tab enters an RST field it could place the cursor under the first '9' and from there the field edited as needed. I'm afraid I don't have the time to code it for some months so maybe someone else can pick up the idea if it is thought to be a good one and add it. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Real RST possible?
First, I know there is the CHANGE_RST directive, but for QRP contests (at least in the states), many times ops send an actual RST -- 33N, 439, etc. Is there any way to incorporate this in both the received stations data (I imagine it would be in the exchange field, like a serial number) and for the sending station? It would be helpful the above mentioned QRP contests, geneal ragchews and for SOTA operations as well. Thanks! -- Jim KK0U (ex-N0OCT)
