View Issue Details

IDProjectCategoryView StatusLast Update
0002576Ham Radio DeluxeBugpublic2018-11-11 00:34
ReporterPD9FER 
Assigned ToK7ZCZ 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version 
Target VersionFixed in Version6.4.0.902 
Summary0002576: Command SPLIT not work properly IC-7610 HRD Build 794
DescriptionSelect a station on the DX cluster with comment UP5 the radio follow the SPLIT frequncy on Main VFO and not on the secondary VFO
Steps To ReproduceAs in description
Additional InformationTicket #340979
TagsNo tags attached.
ModuleLogbook
Sub-ModuleRadio Support
Testing Beta Successful

Relationships

Activities

WA9PIE

2018-03-08 20:18

administrator   ~0004454

Uploading contents of ticket here.

Ticket-340979.pdf (99,102 bytes)

K7ZCZ

2018-11-01 17:47

manager   ~0006358

This is a difficult issue to approach because there's not much information to go on. Neither the Logbook documentation nor the Rig Control documentation describes "split mode", aside from mentioning an option in the DX Cluster options page. This issue itself doesn't contain particularly useful repro steps. The provided ticket text contains the additional detail that the customer seems to theink the functionality works fine with their IC-7700 V2 radio.

With so little to go on, I spent several hours reverse-engineering the application and its source code to try to get a handle on the problem. This note summarizes my findings.

The DX Cluster dialog's implementation has some code that parses the comments for each spot to see if it contains text like "UP n" or "DN n", plus a few similar spellings and spacings. The "n" value is a frequency that defines the split operation. I expect that this feature allows the user to tune to another station that they've been advised is operating split; if their radio supports it, the radio can use its split feature to tune to the listening frequency and pre-tune the transmit side of the radio for the transmit frequency based on the advice given in the comment of the cluster spot.

Cluster spots may or may not contain split notation, so testing this feature requires connecting to a cluster and hoping a split report comes along. I haven't been able to find documentation that specifies the acceptable split description strings offered in comments, or specifies a mechanism in the protocol which might specify the split report.

When a spot containing split information is selected for tuning, and when a radio that supports split operation is connected, the radio is sent extra commands that drive its split-operation feature. We have the clue offered by the customer in the ticket notes that say the feature works fine with the IC-7700 V2 radios, so I used that information to focus my investigation.

The DXClusterDlgSplit.cpp file contains an implementation for a SplitOn() method, which has this fragment for the IC-7700 (and a few other radios):

// split on

        else if( ( strRadio == ( "IC-7600-V2" ) ) || ( strRadio == ( "IC-7100-V2" ) ) || ( strRadio == ( "IC-7700-V2" ) ) || ( strRadio == ( "IC-7800-V2" ) ) )
        {
            HRDInterfaceFreeString(HRDInterfaceSendMessage(_T("set button-select A~=~B %d"), TRUE));
            Sleep(100);
            HRDInterfaceFreeString(HRDInterfaceSendMessage(_T("set frequencies-hz 0 %d "), nFreq));
            SetSplit();
            //	HRDInterfaceFreeString(HRDInterfaceSendMessage(_T("set button-select Split %d"), TRUE));
        }


A SetSplit() method makes a similar call with the split button, passing "1" as the parameter:

// set split
        else if ((strRadio == ("IC-7600-V2")) || (strRadio == ("IC-7100-V2")) || (strRadio == ("IC-7700-V2")) || (strRadio == ("IC-7800-V2")))
        {
            Sleep(100);
            HRDInterfaceFreeString(HRDInterfaceSendMessage(_T("set button-select Split %d"), TRUE));
        }


and SplitOff() method sends the "Split" command with a parameter of "0".

// split off

        else if ((strRadio == ("IC-7600-V2")) || (strRadio == ("IC-7100-V2")) || (strRadio == ("IC-7700-V2")) || (strRadio == ("IC-7800-V2")))
        {
            HRDInterfaceFreeString(HRDInterfaceSendMessage(_T("set button-select Split %d"), FALSE));
        }


In SplitOn(), the "button-select" command is sent to the rig control application with the parameter "A~=~B", where the tildes are substituted for spaces; so this code is asking the Rig Control application to behave as if the user has pressed the "A = B" button in the UI. For the IC-7700 V2 radio, this sends the command 0x07, 0xA0, which the manual documents as "Equalize VFO-A and VFO-B".

The following call for "set frequencies-hz" sets the frequency for the B-side of the radio. The "0" first parameter leaves VFO-A unchanged.

The "set button-select Split 0" and "set button-select Split 1" commands send the "split" command to the radio. For the IC-7700 V2, this sends command 0x0F with parameter 0x00 (for off) or 0x01 (for on).

When selecting a spot, the A VFO is set to the spot's fundamental frequency. The comment in the spot is paresd with a helper function named QSX(), which has a some convoluted code to try and deduce the direction, position, and frequency of the split frequency. The QSX() implemenattion has significant amibguity and probably has bugs.

If the QSX() function detects a split frequency, the SplitOn() method is called to set the split frequency as above.

The problem for the IC-7600 is that it's not explicitly handled in any of the if/else logic present in these functions. The backstop code takes a stab at setting setting the split by setting A=B, selecting VFO B, setting the frequency of VFO B to the split frequency, then selecting VFO A. For radios that support all of these commands, that might work; but the IC-7610 is not one of them.

After all of this reverse engineering -- made necessary by a void of information for the feature and the reported issue -- I've added a few lines to support the IC-7610. Modulo the limitations in the QSX() function that parses the comment text, the code seems to work.

The checkin includes a significant cleanup item. The design of both rig control and the Logbook is quite poor when it comes to detecting different radios. The radio name is used with some standardized string. A variable holds that radio name, and the string is repeatedly compared against other strings. The code above, repeated here, demonstrates that technique:

        else if( ( strRadio == ( "IC-7600-V2" ) ) || ( strRadio == ( "IC-7100-V2" ) ) || ( strRadio == ( "IC-7700-V2" ) ) || ( strRadio == ( "IC-7800-V2" ) ) )


This is a pretty poor design, since comparing string literals (especially when the strings in the valid set are usually pretty similar) is expensive for both code size and execution time.

I have not fixed that issue. However, there's a sbutler issue here: strRadio holds a Unicode string, but the string literals used throughout the DXCluster dialog implementation for testing the radio name are always ANSI string. Each invocation of operator== must take the multi-byte string literal and convert it to Unicode before comparison; this is done for the whole string before the comparison starts. Even though the strings are constant and known at compile time, the work is repeated at runtime for every single invocation of the comparison operator.

The checkin fixes this issue by converting all of the strings to Unicode in the source, like this:

        else if(strRadio == _T("IC-7600-V2") || strRadio == _T("IC-7100-V2") || strRadio == _T("IC-7700-V2") || strRadio == _T("IC-7800-V2") )


With that fix, no temporary objects need to be created, no character conversions are invoked. The code reads much cleaner, as I also took the time to remove suprious parenthesis in all the conditional statements.

K7ZCZ

2018-11-01 17:48

manager   ~0006359

fixed with this checkin
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4401

WA9PIE

2018-11-05 00:54

administrator   ~0006369

FWIW - the practice of "UP5" (DN... etc) is very bad. The proper way to do this is with a QSX statement in the comments - "QSX 14.035" or something like that. We eventually need to reconsider the approach. It was ill-advised when it was created.

PD9FER

2018-11-05 12:31

viewer   ~0006387

Send Beta to Customer awaiting his reply

PD9FER

2018-11-06 06:40

viewer   ~0006394

Got feedback from customer.
Fixed in build 900

Issue History

Date Modified Username Field Change
2018-03-06 02:17 PD9FER New Issue
2018-03-08 20:18 WA9PIE File Added: Ticket-340979.pdf
2018-03-08 20:18 WA9PIE Note Added: 0004454
2018-03-15 21:06 K7ZCZ Assigned To => K7ZCZ
2018-03-15 21:06 K7ZCZ Status new => assigned
2018-11-01 17:47 K7ZCZ Note Added: 0006358
2018-11-01 17:48 K7ZCZ Status assigned => resolved
2018-11-01 17:48 K7ZCZ Resolution open => fixed
2018-11-01 17:48 K7ZCZ Testing => Not Started
2018-11-01 17:48 K7ZCZ Note Added: 0006359
2018-11-04 07:48 K7ZCZ Project 1 - Backlog => 3 - Current Dev List
2018-11-04 07:49 K7ZCZ Fixed in Version => 6.4.0.900
2018-11-05 00:54 WA9PIE Note Added: 0006369
2018-11-05 12:31 PD9FER Note Added: 0006387
2018-11-06 06:40 PD9FER Note Added: 0006394
2018-11-08 22:06 WA9PIE Status resolved => closed
2018-11-08 22:06 WA9PIE Testing Not Started => Beta Successful
2018-11-11 00:34 WA9PIE Fixed in Version 6.4.0.900 => 6.4.0.902
2018-11-11 00:34 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe