Joe,
Thank you for your response, sorry to have wasted your time.
Comments inserted below.
73 de Bill ND0B
-----Original Message-----
From: Joe Taylor [mailto:[email protected]]
Sent: Monday, January 2, 2017 1:57 PM
To: WSJT software development <[email protected]>
Subject: Re: [wsjt-devel] Ideas for Development
Hi Bill (ND0B) and all,
I've been away most of the time since your post, and just now finding time
to respond. You gave us a long list of ideas, with no evident
prioritization. You mentioned to me that you were "in the process of
learning C++ and QT by immersion". Of course you're the best judge of your
status in that respect, but keep in mind that it may take some time to get
up to speed.
I am well aware of that, in fact I was pretty much quoting back what you
suggested I do a couple of years ago when my efforts were focused on WSJT
and you suggested I might want to move over to WSJTx. I pointed out that
while I do a lot of C I would be new to C++ and to QT. You suggested I do
what you did and just start doing it. While that email is archived I would
be happy to dig it up.
I deliberately did not put priorities on these as they are self imposed
tasks and as such would be tackled as I feel comfortable doing them and as
such represent a range of difficulties.
A few specific comments:
> 1. Add situational awareness to the auto sequencer. Currently if the
> auto sequencer detects any message it will move to the next one in the
> sequence even if it does not make sense to do so. I plan to add logic
> (which is in the one I added to ISCAT in WSJT) so if you are currently
> sending TX1 you will move forward if RXing a TX1 or a TX2, etc.
Many have been using the auto-sequencing with MSK144 and have not found it
to do things that "do not make sense". A couple of things that I might look
at (but do not consider to be extremely important) are these:
I brought this one up because I have seen a couple of times where the other
station was not well behaved and jumped ahead in the sequence. When this
happens, and it could well have been fixed by now, the auto sequencer does
not ignore the message but rather jumps ahead to the next one in the
sequence.
K1JT ND0B EN07
ND0B K1JT +02
K1JT ND0B RRR // Bad behavior on my behalf.
ND0B K1JT 73 // At least in the past the auto sequencer
responded to the message, not the situation.
ND0B K1JT +02 // What the auto sequencer should respond with to an
out of sequence message.
a) If already sending a report, i.e. Tx2 or Tx3, allow it to replace the
numerical report by a higher number but not with a lower one.
b) If already sending 73, do not allow a "genStdMsgs()" call to overwrite an
entered-by-hand message that I have typed into one of the Tx# fields.
I concur both of these would be good fixes.
> 2. Include MSK144 in the logic for "send 5 73's after last RRR
> received" logic. This appears to be in place for some (one, ISCAT??)
> of the other protocols and it makes sense for it to be on MSK. I find
> myself clicking enable TX several times to make sure this effectively
> happens. I believe this should be enabled by the Disable TX after
> sending 73 click box.
> 3. Make the number of 73s sent after last RRR received configurable.
> It is currently the magic number 5 for the protocol(s) it is
> implemented for.
Motivation for these two seems weak to me. Why are you "clicking enable TX
several times"? I never do that. I don't want the program to determine for
me how many times to send 73; I'm quite capable of doing that myself.
We're not attempting to make an automated QSO machine.
I concur but an automated QSO machine implies much more than what I am
suggesting here. I am not talking about automated responses to CQs and
automatic logging, I am simply suggesting an improvement in how a QSO ends
under the auto sequencer. Currently there are two choices, send 73 once
and stop or send 73 until stopped. I put a lot of thought and work based
on operational experience with this end game into the ISCAT auto sequencer I
put in WSJT and had it working what most considered fairly well. It is a
situation that does not have an ideal solution regardless if it is fully
under human control or if it is automated. My suggestion is to allow an in
between of the two current scenarios that would allow the auto sequencer to
end most contacts gracefully.
> 4. Implement Hamlib rotor control for Az and Hot A: / B: A left click
> on either of these would move the rotor to that direction a. Side
> project: Add Idiom Press and Green Heron controllers into Hamlib. Both
> of these are popular and an offshoot of the Hygain controller protocol
> that inexplicably did not have a facility for getting the current
> position from the controller. Both of these controllers added commands
> to position query but unfortunately is a subtly different manner.
> 5. Add a toggle (on right mouse click) between Hot A: and Hot B While
> it usually displays the right one to use sometimes the radiant is
> obviously on the other side. While the mental gymnastics is easy
> enough to convert it would be nice to just click. and then click again
> to move the rotor.
OK, I guess, but again the motivation for adding rotor control to WSJT-X
seems pretty weak to me. Few users have an antenna for 6 or 2 meters with
beamwidth small enough to be able to tell the difference between pointing at
Hot A, Hot B, or the direct path. It a tough call for me to see any
difference, even with my wide-spaced 4 x 2MXP28 array on 2m.
Lumping the response to the two of these together muddies things a bit. As
to adding rotor control in general would certainly be an improvement over
mentally and physically moving the reported azimuth over to whatever rotor
control program the user is using. I believe that a reasonable thing to
do. As to the differentiation between AZ, Hot A and Hot B, I concur those
are not significant for long distance contacts however they become key in
short distance contacts when both stations end up aiming to one side or the
other in order to catch the radiant at an elevation that is in the antenna
gain pattern. If the effort is made to add rotor control (which I believe
is justified) then the additional effort to add Hot A / B to that is not
that great.
> 6. Make entry of DX Grid so it is not so persnickety. This is a simple
> one trimming leading or trailing white space off. I find that my usual
> way of getting ahold of the grid, copying it out of PJClient, often
> has a leading or lagging space, the entry box does not like this.
I've never found grid entry to be difficult. By all means, make it better
if you see how.
Again, if you are copying and pasting and have a leading or lagging white
space the entry is rejected. Maybe it is just how I use the mouse but this
seems to happen to me a lot when I copy from PJ Client.
> 7. Add 60s sequences to the fast modes. I know you have had a
> discussion with Ged W8BYA about this, he would like it so he can
> operate diametrically opposed to some local high power EME stations, I
> find that a reasonable request. I would like it because I am planning
> some long term (24+ hour) runs and would like to increase the active
> time. With
> 15 second sequences approximately 4 seconds out of 60 are spent in
> changeover, with 30 second sequences 2 out of 60 and with 60 second
> sequences this is 1 second out of 60. This small but appreciable
> difference help up the chances of success on a long term run that is
> dependent on low probability events. Not by much but enough to make
> the effort worthwhile.
Nearly everyone uses 15s sequences, and it's a big advantage to have a
standard. We allowed for longer and shorter ones, mainly for testing and
specialty purposes.
I concur COMPLETELY for day to day contacts. but that begs the question of
why do we have other sequence lengths, why do we have a contest mode, why do
we have an option on SH. It is because people like to experiment and
will.
One minute sequences? Surely the difference between a "sequencing time
loss" of 1/60 or 2/60 is not worth a big programming effort. For your
special 24-hour run, why not just extend it by another few minutes, to make
up the difference?
This reply assumes the probability of a ping is distributed equally over the
operating period.
> 8. If it will fit add a "what the heck I am doing" letter to the CQ
> message for MSK144. This would be a single letter representing the T/R
> period, SH status and Contest Mode status. Clicking on this in an RXed
> CQ would change things to match. Because space is limited this would
> be done by convention using a table...
If you want to try this, I suggest playing with the existing capability to
send "CQ AA" through "CQ ZZ". Keep in mind, though, that these are already
used for such things as "CQ DX", "CQ EU", "CQ VT", etc., etc.
As Bill G4WJS pointed out there are is a large range of these available and
that you had grabbed AA - ZZ. As these apparently already have use it
would seem to make more appropriate to set aside a range for this new
purpose.
Again, my gut feeling is that we're better off using standard procedures for
everything but special-purpose tests (which of course you can pre-arrange).
For standard random-QSO operating, use 15 s sequences; no Sh on 6m; do use
Sh on 2m and higher; use contest mode during contests (or by arrangement).
Keep in simple.
I concur completely. However the only way to enforce that is to remove the
options. Only allow 15s sequences, force SH based on band, impose contest
mode based on calendar. And end up with a riot. As long as there are
options there will be folks that use them on a day to day basis. And there
will be new users who have yet to learn the standard procedures. This
change would remove the ambiguity from those situations.
Anyway, those are a few initial thoughts...
-- 73, Joe, K1JT
----------------------------------------------------------------------------
--
Check out the vibrant tech community on one of the world's most engaging
tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
