Real RST possible?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Real RST possible?

jim smith-3
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)

Reply | Threaded
Open this post in threaded view
|

Re: Real RST possible?

Nate Bargmann-4
* 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 (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Real RST possible?

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
>

Reply | Threaded
Open this post in threaded view
|

Re: Real RST possible?

Thomas Beierlein-4
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&P 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 <[hidden email]>:

> 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
--


Reply | Threaded
Open this post in threaded view
|

Re: Real RST possible?

Nate Bargmann-4
* 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&P 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&P 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 (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Real RST possible?

Thomas Beierlein-4
Am Tue, 28 Jan 2020 07:55:47 -0600
schrieb Nate Bargmann <[hidden email]>:

> * 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&P 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&P, 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&P 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
--


Reply | Threaded
Open this post in threaded view
|

Re: Real RST possible?

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.

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



Reply | Threaded
Open this post in threaded view
|

Re: Real RST possible?

jim smith-3
In reply to this post by Thomas Beierlein-4
On Tue, 28 Jan 2020 20:13:04 +0100
Thomas Beierlein <[hidden email]> 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&P 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

Reply | Threaded
Open this post in threaded view
|

Re: Real RST possible?

Thomas Beierlein-4
In reply to this post by Csahok Zoltan
Am Tue, 28 Jan 2020 21:42:06 +0100
schrieb Csahok Zoltan <[hidden email]>:

> > > 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<enter>' or similar in the comment field
to override the received RST. 'r' makes clear that is it no exchange,
<enter> 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
--


Reply | Threaded
Open this post in threaded view
|

Re: Real RST possible?

Thomas Beierlein-4
In reply to this post by jim smith-3
Am Tue, 28 Jan 2020 16:47:05 -0600
schrieb jim smith <[hidden email]>:

> On Tue, 28 Jan 2020 20:13:04 +0100
> Thomas Beierlein <[hidden email]> 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&P 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
--