RE: [wsjtgroup] WSJT-X v0.8 r3118 Observations & Recommendations (rev-1).
I must chime in here… I am nearly 100% in agreement with the suggestions offered by KI7MT
Warning, Long Post so if you get bored easily, bail out now :-)
I'vebeen using the latest version for a couple days now, I've made closeto 50-75 Q's thus far and overall, things have been pretty smooth.Just a few observations / recommendations which I think may beuseful, all be it, these are my personal preferences and certainlynot show stoppers.
WhenI talk to folks about switching to WSJT or WSJT-X, most say one of two things, they never heard of WSJT / WSPR application(s) ( how that can be I have no Idea ), or they find it's too complicated to use. Maybe afew of these items could help, who knows. In any case here we go:
TX / RX Messages: S&P seems logical in order, but when I'm CQ-ing, it seems to me the CQ <call> <grid> line should be first (TX1) after I hit Generated MSG's, and TX6 should be the custom message box. Custom messages are normally last action in the sequence but not always I suppose, so being at the bottom kind of make sense. I'm not sure why we need two different RST formats, one with and the other without the "R", but I tend to use the one without, mainly because the application defaults to that format. I've not tracked this, but a general feeling is about 60/40 without R "<call> <call> +00" with R "<call> <call> R +00" respectively.
Enable TX on Double-Click S&P: I've messed this up many times now because I did not manually enable TX when somebody called CQ, and I tried to work them. Watching the waterfall, watching the decodes, getting excited to see a new one, double-click, and nothing happens, Total Bummer!! By the time you realize what's gone wrong, your 10 seconds into the sequence. I'm sure there's logic behind defaulting to RCV after double-clicking a CQ, but it seems to me that if I did not intend to call them, I would not have clicked their call. Additionally, I've found with some call signs, or large numbers of decodes, there is very little time ( 1 to 2 seconds maybe ) between decode, selecting the caller, and hitting the TX button. It's not a problem on some bands yet, but on busy bands like 15m/20m where you can get 8 to 10 decode lines per cycle, leaves very little time for action on the S&P side. Inf fact, a few times today in fact I was sent 73's again by mistake, which I'm sure they just missed or forgot to RX after the QSO, same as I've done several times before. I hear it quite often now that I'm listening for it, short little TX followed by an abrupt stop :-) Of course, while your running a frequency, one would not want the TX to switch off after logging the QSO.
Decoded Test Area: This is a rough one for me, probably my number one issue thus far. Having the newest decodes on the bottom is causing me all kinds troubles, as I'm constantly going after the scroll bar / button to see if I'm at the bottom of all the stack, then looking for a return message or CQ, then double-click and somehow remember to hit the TX button too :-) There is very little time to find the line, double-click and hit the TX and make it before the line passes for TX and your off by a second or two at that point. On a slow band, this has not been as big of a problem, busy bands with lots of decodes, major problem, at least for me. The current coloring coding helps a little, but only marginally. I think reversing the decodes, with the newest on top, eliminating the new Grey-Line separator and color coding the lines would "Help Allot". I realize fixed colors & fonts are not always best for visually impaired or color blind folks, so maybe making this a configurable item would be best, with a default along the lines of; Grey = An in process QSO; Red = Your call sign is in the line; Green Go Go Go Go, they're CQ'n :-) and allow the user to change things to suit their needs.
Separated Waterfall & Main GUI: I'm sure there's a reason for this, but when JT-Alerts-X comes along, we're going to have 3 windows to manage and lord only knows what else folks have going on their desktops. FFT Bins and N Avg are cool features, I use them rather often. But I've yet to run into a situation, when I'm actually using the application, not in monitor mode, where I've needed more than 1.5Khz of waterfall space if that, others may differ. Maybe when things heat up for JT9-1, I'll need more space, or maybe the longer time modes need this, not sure, but for JT9-1, from my perspective, having to manage two boxes doesn't' seem necessary and just complicates my desktop even more than it's already is :-)
Cat Control Behavior - Bad Cluster Spots: I'm not sure if this is a bug or normal CAT behavior. I run an FT-1000MP and FT-2000D, both are working fine for the most part. TX/RX and band switching from he pull-down. However, one thing has caused me to send incorrect spots several times. I'm in the habit of using the Rigs Memories for Band / Mode shifts, and my CAT enabled applications normally follows the rig. This doesn't seem to happen with WSJT-X. Works like a champ if I use the band selector pull-down, even puts me where I need to be in the band. However, if I manually select a band with the rig, bypassing the application pull-down, I start sending spots for the wrong band as soon as it decodes someone. I've not checked the logging, but I would imagine this would be an issue there also, e.g. logging the wrong band or no band data at all. Is this a bug or intended behavior, I don't know, but I think this one should be looked at for sure.
That'sit for now. If there's a bug list going, there's a few things (veryminor ), which I'm sure are bugs that I can report, mainly visualimpacts, none are functional in nature.
Overall, I Think It's a Great Application / Mode. Only needing 5W to work EU from Western MT, in the late afternoon is pretty awesome in my book :-)