View Issue Details

IDProjectCategoryView StatusLast Update
00029303 - Current Dev ListBugpublic2019-01-29 02:36
ReporterK7ZCZAssigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Product Version6.4.0.899 
Target VersionFixed in Version 
Summary0002930: Documentation: "Split" feature of DX Cluster is undocumented
DescriptionThe product documentation includes no information about the split feature of the DX Cluster
Steps To Reproduce
1) Read the docs for the Logbook, looking for "Split" (or QSX, or any other term you might guess ...)
BUG#1) Find nothing.

TagsNo tags attached.
ModuleLogbook
Sub-ModuleDocumentation
TestingNot Started

Activities

WA9PIE

2019-01-27 22:31

administrator   ~0007093

In my opinion, the previous developers took a request from users and then took action on it without gathering (or ignoring) details. As such, it's FAR harder than it should be.

There's another aspect of this problem that was not covered in the initial implementation that has to do with SENDING split spots. We do NOTHING about sending split spots. It's appropriate to discuss SENDING spots first. Then I'll discuss actions taken on those spots.

Let's make this simple:

The correct way to communicate a split frequency in the DX cluster is by using QSX.

Example - "QSX 7024.2" is the correct way to announce the TX frequency for split.

The format for sending spots is: dx [by <call>] <freq> <call> <remarks>

In this example, the software would send something like this: "dx na4j 7014.0 QSX 7024.2" (without quotes) [Image attached of what that would look like in Logbook's Send DX Spot dialog box.]

The CC11 string received by a DX Spider node would look like this:
CC11^7014.0^HK0RMR^27-Jan-2019^2303Z^QSX 7024.2^NA4J^78^226^K4JW^11^7^8^4^ ^NC^San-Andres-Providencia-HK0/A^Alabama-K^^EM96

So here's problem #1 - we don't SEND the split frequency... at all. If we expect to be able to take actions on split spots in the DX cluster pane, we need to send in the proper format.

NOTE: When do we send this QSX thingie? We send QSX when the user's rig is in Split mode and they attempt to send a spot. This adds at least two steps to the current process. One - we check to see if the radio is in split mode. If so - then two, we get the frequency from the TX VFO and pop it into the "Remarks" field with "QSX " inserted in front of it. We allow the user to change what's in the remarks field (often they may append text to it).

The reason why this is so important is that it eliminates the random variation of how split is announced. It also makes it easier for the user.

Okay... so that covers the sending part.

Then - to cover current functionality in the DX cluster pane - we should get rid of all other methods for parsing out split except for two.

One - when the Remarks field contains "QSX frequency", we should set the TX VFO and put the radio in split.

And two - only because it's common we should also honor "up x" or "dn x"... where x is an integer that is added to the RX frequency and that is what's used to set the TX VFO. (As I say, only because it's common... not because I think it's a good idea.)

Sticking with our example, if we receive the following CC11 string:

CC11^7014.0^HK0RMR^27-Jan-2019^2303Z^up 10.2^NA4J^78^226^K4JW^11^7^8^4^ ^NC^San-Andres-Providencia-HK0/A^Alabama-K^^EM96

This should have the same effect. that is... the RX frequency (7014.0) plus the "up" (10.2) = the TX VFO frequency (7024.2).

Trying to parse anything else is a complete mess and should be avoided.

QSX HK0RMR.PNG (26,373 bytes)
QSX HK0RMR.PNG (26,373 bytes)

K7ZCZ

2019-01-28 14:57

administrator   ~0007108

This issue is about updating the customer-facing documentation for the feature. If there are prolems in the implementation, I think those issues should be raised in their own Mantis issue (or issues). When Mantis isuses start tracking multiple issues, they get a lot harder to manage, track, and work.

WA9PIE

2019-01-29 02:36

administrator   ~0007114

I can understand the need to split things up. That said, I don't think anyone can write documentation for a feature that (a) no one really knows how it was coded or implemented and (b) bares no resemblance to how it should actually work. It would be a complete guess. If I knew how it was coded and/or implemented, I suppose I could attempt to document the "as-is" state of this feature. But I would immediately want to change it to make it usable and less complicated.

My gut feeling is that there's much more in this than just the standard QSX and up/dn x. But I don't know. If a review of the code reveals that these are the only methods implemented, then WOW... that's great! I'll write the documentation for that and we'll work up the SEND part in a separate Mantis enhancement issue. But as I say... I really doubt it was done this way.

Let me know how you would like to proceed. I think this is an important item.

Issue History

Date Modified Username Field Change
2018-11-01 23:33 K7ZCZ New Issue
2019-01-27 22:31 WA9PIE File Added: QSX HK0RMR.PNG
2019-01-27 22:31 WA9PIE Note Added: 0007093
2019-01-28 14:57 K7ZCZ Note Added: 0007108
2019-01-29 02:36 WA9PIE Note Added: 0007114