On 09/12/2019 19:05, John W9ILY wrote:

Bill,
What I was referring to is exactly when should the number of streams be changed? Obviously not during a TX sequence but is during an RX sequence OK?
John

Hi John,

it doesn't matter, the effect is only at the net transmission period start when WSJT-X chooses how many streams to use.

73
Bill
G4WJS.

Sorry, type there. I meant "... only at the next transmission period start ..."

73
Bill
G4WJS.

On 09/12/2019 19:05, John W9ILY wrote:

Bill,
What I was referring to is exactly when should the number of streams be changed? Obviously not during a TX sequence but is during an RX sequence OK?
John

Hi John,

it doesn't matter, the effect is only at the net transmission period start when WSJT-X chooses how many streams to use.

73
Bill
G4WJS.

Bill,
What I was referring to is exactly when should the number of streams be changed? Obviously not during a TX sequence but is during an RX sequence OK?
John

   I don't have the all out solution but I would rather have it log one time and be a minute or so off and it will still be confirmed in both logs than have 2 or 6 dupes... maybe a check in the settings allowing each user to decide. Regards Shawn KU0D   

On 09/12/2019 18:32, John W9ILY wrote:

Thanks, Bill. One further question: when do you suggest is the best time to change the number of slots? During an RX session or at a different time?
John W9ILY

Hi John,

hard to answer that definitively. If the signal reports start dropping and the rate decreases then that may be a time to reduce the number of slots, on the assumption that Hounds are missing their RR73 messages due to fading below the decoding threshold at their end. The Fox operator needs to keep in mind that when multiple slots are active the link Tx power is likely to be asymmetric in favour of the Hound unless the Fox transmitter is QRO.

73
Bill
G4WJS.

Thanks, Bill. One further question: when do you suggest is the best time to change the number of slots? During an RX session or at a different time?
John W9ILY

John, Bill,

perhaps another approach would be to think of the data flow and how integrity of the contact log is maintained. Currently WSJT-X has data integrity since a log entry is made at the point at which a QSO seems to be finished. If the finish sequence re-appears, then another record is made. The logic for this is simple, and there is no danger of a QSO not being recorded in the log if, for example, something crashes.

That being the case, then the log from WSJT-X may, necessarily, contain duplicates. Removing those duplicates then becomes a process that may be achieved either by some stand-alone program or in a logging program.

It seemed so much easier with paper logbooks, but probably not for TO9W!

73,

Robin, G8DQX

On 09/12/2019 15:37, John W9ILY wrote:

Hi Bill.
Yes, we are using 2.1.2 and understand the process. It would be good if, in the future, a second or third transmitted RR73 within a 2 minute period, for example, did not create additional log entries. However, that might cause an additional problem with the time of the transmitted RR73 and the received RR73 being slightly different. Anyway, the program is really working fine for us at TO9W.
73,
John W9ILY

Hi John,

glad things are going well apart from the dupes in the log. I am sure you have worked this out, but take care to have the number of slots allowed set appropriately for the propagation conditions and traffic levels. Having the number of slots increase mid QSO may cause Hounds to miss their RR73 messages. Try and keep the wait queue size greater than the number of slots, if it falls below the number of slots then reduce maximum slots to try and keep Fox power levels per QSO stable.

Understood about your suggestion to limit dupes over a small time period, that could be implemented although it would be much more complex than the prior arrangement that used database table constraints to disallow dupes. The v2.1.2 code simply removed the constraint so all dupes are allowed.

I also wonder if suitable transmitter power levels are being used by Fox stations. I estimate that a popular Fox station needs about 500W output to be able to run 5 slots effectively, but of course in a DXpedition that level of power is not always possible, particularly if there are other positions active on phone or CW on the same band.

73
Bill
G4WJS.

Hi Bill.
Yes, we are using 2.1.2 and understand the process. It would be good if, in the future, a second or third transmitted RR73 within a 2 minute period, for example, did not create additional log entries. However, that might cause an additional problem with the time of the transmitted RR73 and the received RR73 being slightly different. Anyway, the program is really working fine for us at TO9W.
73,
John W9ILY

Good decision Bill.
Yes, dupes are better than missed confirmations for valid QSOs.

73
Martin 9A2JK

On 09/12/2019 01:07, John W9ILY wrote:

We are at TO9W using FT8 in addition to CW, SSB and RTTY. As you can imagine we have many callers and have found F/H quite helpful. We have noticed that, on a number of occasions when using FT8 F/H, the calling station does not receive our RR73, he resends his report and we resend the RR73 and the QSO completes. This results in a QSO logged for both of the RR73 transmissions from us. Sometimes this happens three times and there are three loggings for one QSO. Perhaps a future build would include some means of preventing this duplication of QSO logging.
73,
John W9ILY

Hi John,

I assume you are using the latest WSJT-X v2.1.2, this was intentionally changed to log dupes, prior versions did not log dupes. The reason was that when dupes were ignored many stations were not getting confirmations because the Fox logged the first time an RR73 message was sent but the Hound may log considerably later when they successfully received an RR73. The  subsequent log entry time difference causes mismatches on services like LoTW. We have decided that dupes are better than missed confirmations for valid QSOs.

73
Bill
G4WJS.

We are at TO9W using FT8 in addition to CW, SSB and RTTY. As you can imagine we have many callers and have found F/H quite helpful. We have noticed that, on a number of occasions when using FT8 F/H, the calling station does not receive our RR73, he resends his report and we resend the RR73 and the QSO completes. This results in a QSO logged for both of the RR73 transmissions from us. Sometimes this happens three times and there are three loggings for one QSO. Perhaps a future build would include some means of preventing this duplication of QSO logging.
73,
John W9ILY