Win-Test

for Project:

Welcome to the Bug Tracking System for the Win-Test contest logger. Things to note :

Feel free to report any bugs, however minor. To improve efficiency, please try to be as accurate as possible.

Please don't ask for feature requests here but on the mailing list.

Thanks for your help. Olivier F5MZN and Laurent F6FVY

Task #159 — Incorrect Frequencies when split, Grab Spot and ALT-F4

Attached to Project— Win-Test
Opened by Bill Myers (K1GQ) - Thursday, 8 Nov 2007, 4:16pm
Last edited by F5MZN (f5mzn) - Friday, 28 Dec 2007, 12:11pm
Bug Report
Radios
Requires testing
F5MZN (f5mzn)
All
Critical
Normal
WT-3.1.x
Undecided
90% complete

WT 3.18.0, Orion II, LSB mode (both VFOs), SO1R/Multi-Op technigue.

Steps to reproduce:

(1) Tune radio: RX(VFO A) 7099.0 TX(VFO B) 7198.0.

(2) Self-spot: CTRL-ENTER. Correct result appears in band map with \"QSX 7099.0\" comment.

The first two steps merely set up a spot with QSX to demonstrate the problem.

(3) Tune radio: RX(A) 7045.0 TX(B) 7205.0.

(4) Set CQ Frequency: ALT-F5.

(5) Grab the self-spot: double-click in band map. Result is RX(A) 7045.0 (should be 7099.0), TX(B) 7099.1 (should be 7198.0), both are incorrect.

(6) Return to run frequency: ALT-F4. Result is RX(A) 7045.0 (unchanged), 7045.1 (should be 7205.0). RX happens to be right because it wasn\'t changed earlier, TX is incorrect.

(7) Return to spot frequency: ALT-F4. Result is RX(A) 7045.0 (should be 7099.0) TX(B) 7045.0 (should be 7198.0). Perhaps this behavior is not implemented in Win-Test, but it is standard in CT.

I believe NQ4I reported this bug with a different radio on the Win-Test mail list after CQWWPH 2007.

This task depends upon

This task blocks these from closing

Comments (16) | Attachments (0) | Related Tasks (0/0) | Notifications (3) | Reminders (0) | History |

Comment by Bill Myers - Wednesday, 12 Dec 2007, 2:35pm

2007.12.12 K1GQ Logged sequence of commands to radio when double-clicking a spot with QSX (excluding queries) (1) Set VFO A to spot transmit (QSX) frequency (?) (2) Set Main receiver mode (3) Set VFO A to previous receive frequency (!) (4) Set VFO B to spot transmit (QSX) frequency (5) Set Sub receiver mode (6) Set VFO assignments to \'ABB\' (Main receiver, transmitter, Sub receiver)

Neither VFO is ever set to the spot receive frequency -- where the DX is transmitting.

Comment by Bill Myers - Friday, 14 Dec 2007, 6:01pm

I\'ve learned how to monitor the data transferred between Win-Test and the radio using the logging feature in microHAM USB Device Router. For example, I can see problems in the sequence for the case of a QSX spot, which I\'ll be happy to document if it would be helpful.

Also, I have plenty of time and motivation to support testing Win-Test + microKEYER + Orion II if that would help.

-- K1GQ

Comment by F5MZN - Friday, 14 Dec 2007, 6:15pm

Yes, please tell what is wrong in the current sequence.

Tks in anticipation.

Comment by Bill Myers - Friday, 14 Dec 2007, 6:55pm

Annotated data sequence when grab spot: VQ9JC 7012.0 QSX 7014.3

-> ?RMF // request main receiver bandwidth; not needed

-> *BF7012000 // set VFO B frequency; should be setting A VFO

<- @RMF610 // main receiver bandwidth; not needed

-> *RMM2 // set main receiver mode; maybe not needed

-> ?RMF // ; not needed, and duplicate of first command

-> AF7012800 // set A VFO; but to *wrong frequency (prior A VFO freq)

<- @RMF610 // unneeded and duplicate response

-> ?RSF // request sub receiver bandwidth; not needed

-> *BF7014300 // set VFO B frequency; OK

<- @RSF610 // response to unneeded request

-> *RMM2 // unneeded duplicate command

-> *RSM2 // set sub receiver mode; maybe not needed

-> *KVABB // set VFO assignments (main RX A, sub RX B, TX B); maybe not needed

-> means from WT to radio; <- means to WT from radio.

Further comments:

(1) \"maybe not needed\" applies if the software can check whether a mode or VFO assignment change is needed before issuing the commands. Omitting commands that don\'t change anything would make grabbing spots significantly faster.

(2) The requests for receiver bandwidth may be related to a very old bug fix that I saw in the release notes, which said that setting the VFO frequency was changing the bandwidth. However, WT is not resetting the bandwidth after setting the VFO frequency, so the bandwidth requests seem superfluous.

(3) CTWin does this, for the same spot (CTWin assumes that both VFOs are already set to the right mode):

-> *AF7012000

-> *BF7014300

-> *KVABB

(4) [Aside] CTWin does polling more efficiently, by sending all requests first, then reading all the responses, then doing whatever processing is needed. The Win-Test polling sequence spans about 450 ms, while the CTWin polling sequence spans 63 ms. CTWin monitors one less parameter than WT, the sub receiver mode.

-- K1GQ

Comment by F5MZN - Friday, 28 Dec 2007, 10:21am

Bill, I\'m trying to repeat the problem. Can you confirm that the split mode was already ON before grabing the VQ9JC spot (see above)? 73 de Olivier / f5mzn.

Comment by F5MZN - Friday, 28 Dec 2007, 12:08pm

Done some modification in order to correct the problem and to get QSX frequencies programmation a bit faster.

To be tested from the nightly snapshots starting from dec 29, 2007.

Note to Bill: sri for mistake, the snapshot won\'t be available before tomorow at least (it depends also on Larry who is maybe away for the xmas holidays)

Comment by Bill Myers - Friday, 28 Dec 2007, 4:32pm

Olivier, I don\'t see any change in behavior with today\'s 3.19.0-dev downloaded 30 minutes ago. Here is what happens when I grab a simplex spot with split mode on (this is how I always operate CW, no RIT):

(1) A = 14.007.000 B = 14.007.000 RX = A TX = B

(2) ALT-F5 to set CQ frequency.

(3) Grab simplex spot on 14.012.8:

A = 14.007.000 B = 14.012.800 RX = A TX = A -- set wrong VFO A !

(4) ALT-F4 to return to CQ frequency:

A = 14.007.000 B =14.007.000 RX = A TX = B -- correct.

In all cases, the VFO readouts and active VFO highlighting in the Radio 1 window match the actual radio settings.

I am sorry it is hard for me to test grabbing spots with QSX because there are so few of them, and self-spotting a split sets the wrong TX frequency (bug ID 182).

Regards, Bill K1GQ

Comment by F5MZN - Friday, 28 Dec 2007, 5:28pm

To be tested from the nightly snapshots starting from dec 29, 2007 @ 0500z.

Note to Bill: sri for mistake, the snapshot won\'t be available before tomorow at least (it depends also on Larry who is maybe away for the xmas holidays)

Comment by Bill Myers - Monday, 31 Dec 2007, 8:27pm

Tested with 31 December snapshot.

(1) Double-clicking a spot with QSX (\"14082.0 PY0XX QSX 083.4\") works correctly, with radio initially in either transceive or split. The frequency change seems faster as well. Very nice!

(2) When initially split, double-clicking a simplex spot sets the mode and the B VFO, but not the A VFO, which is incorrect behavior since the radio is set to transceive on the A VFO. Double-clicking the same simplex spot again does set the A VFO correctly. So a work-around for this bug is a double-double-click :-)

-- Bill

Comment by F5MZN - Thursday, 3 Jan 2008, 7:54am

Tks for report, Bill.

Is it acceptable to always set VFO A (main VFO), regardless of the current active VFO on the radio?

-- Olivier

Comment by Bill Myers - Thursday, 3 Jan 2008, 2:26pm

I believe that it is always acceptable to set VFO A when QSYing to a spot, QSYing to the run frequency (Alt-F5), or changing radio frequency by typing numbers into the callsign field.

-- Bill

Comment by F5MZN - Thursday, 10 Jan 2008, 7:26pm

Next nightly snapshot will always set VFO A (Main VFO) regardless of the active one.

Tks in anticipation for your tests.

73 de Olivier

Comment by Bill Myers - Friday, 11 Jan 2008, 4:32pm

New (incorrect) behavior:

(1) Initially split, Alt-F5 to set CQ frequency, VFO A is RX on 14010000, B is TX on 14011000.

(2) Grab simplex spot on 14013000; VFO A jumps quickly (nice!) to spot frequency, VFO A becomes both RX and TX, VFO B frequency does not change. Correct.

(3) Alt-F4 to return to CQ frequency. VFO A remains RX, VFO B becomes TX. VFO A initially jumps to CQ RX frequency, then changes back to spot frequency. VFO B changes to CQ RX frequency (wrong) at the same time that VFO A is changed to spot frequency (wrong).

Here is the sequence of CAT commands caused by Alt-F4, with interspersed polling commands removed:

  • Get main receiver bandwidth

  • Set VFO A to 14010000

  • Set main receiver mode to UCW

  • Set main receiver mode to UCW

  • Get main receiver bandwidth

  • Set VFO A to 14010000

  • Set main receiver mode to UCW

  • Get main receiver bandwidth

  • Set VFO A to 14013000

  • Get sub receiver bandwidth

  • Set VFO B to 14010000

  • Set VFO assignments to main RX A, sub RX B, TX B

  • Set main receiver bandwidth to 710

  • Set main receiver bandwidth to 710

  • Set man receiver bandwidth to 710

  • Set main receiver bandwidth to 710

The duplicated commands above are really in the sequence. For example, the main receiver bandwidth is set 4 times in a row (and the sub receiver bandwidth is not set).

Is there something I can do to help further, short of shipping an Orion to France? :-)

-- Bill

Comment by F5MZN - Sunday, 20 Jan 2008, 6:57pm

I have modified this but not tested. Can you give it a try please? Tks.

NB: Not yet included in the nightly snapshot ; this will be done in the next one (Jan 21, 2008).

73 de Olivier / f5mzn

Comment by Bill Myers - Monday, 21 Jan 2008, 4:32pm

WT-dev dated 2008.01.21

Better! ALt-F4 restores VFO to correct CQ receive frequency, but VFO B is restored to the wrong frequency (receive instead of transmit). Here is the new sequence of CAT commands, after jumping to a split spot from CQing on A = 24895000, B = 24896000:

  • Get main receiver bandwidth

  • Set VFO A to 24895000 (correct)

  • Set main receiver mode to UCW

  • Set main receiver mode to UCW

  • Set VFO B to 24895000 (incorrect, should be 24896000)

  • Set VFO assignments to main RX A, sub RX B, TX B (correct)

Nearly all of the duplicated commands are gone -- very good detective work Olivier.

I also confirmed that the radio polling sequence is returning correct data for the split run frequencies to WT.

73 -- Bill

Comment by Rick Dougherty - Wednesday, 20 May 2009, 11:48am

Using Orion not a II...still have problem with grabbing a spot from band map changing the mode from USB to LCW....de Rick NQ4I