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.