>> As for the other case that Eric mentioned (band hopping _not_ selected, band >> set to 630m, TX enabled). For this case, my proposal was to still use the >> same 10x6 tx table to control whether or not to TX. In fact, I tested this >> here over the weekend using 40m (band hopping not selected, band set to 40m, >> TX enabled) and it seemed to work OK. I tested it again just now by >> unchecking the band hopping box after a hop to 30m. It seems to work fine - >> on the next cycle the band stayed on 30m and the rig transmitted according >> to the schedule in the tx table. > That seems a bit artificial to me and quite hard to explain to users > especially given the very low resolution of the Tx percentage chosen when > using the coordinated schedule. Perhaps I am misunderstanding, are you > suggesting that uncoordinated Tx happens when any coordinated slot/band is > marked for Tx regardless of the band in the coordinated table?
Bill, Yes, I think that what you said is what I am suggesting. I would put it this way — the transmission table is merely a schedule for when to transmit, independent of whether transmission is going to occur on a randomly selected band while hopping, on a coordinated band while hopping, or on an arbitrary band while not hopping. The tx table is carefully constructed ahead of time to produce the requested percentage of transmits and the requested (but currently hardwired to 2) maximum number of successive transmissions and a guaranteed minimum number of transmissions per hour per coordinated band slot. The last constraint is irrelevant for the non-coordinated bands or when not hopping - but the first two are still relevant in both cases. Note that the hopping table _guarantees_ that the expected number of transmissions (plus or minus one) will occur in a 2-hour time window. Yes, it’s artificial — but it provides a random (as in non-repeatable) transmission sequence that satisfies two constraints. It’s hard to do that if you want to make decisions about whether or not to transmit “on the fly”. Steve k9an ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
