Randomizing WSPR TX Percent - revisited

After 12 hours or so of experiencing my recent changes to how often my WSPR beacon transmits, I have decided that I am not happy with the results.  As mentioned in my previous posting my recent changes have redefined TX Percent to mean the maximum amount of time that the beacon will wait between transmissions.  This is not quite right because as you can see it results in an aweful lot of transmissions when the intent is to transmit "about every 10 minutes" when TX Percent is set to 20%.

I think clearly that the intent from Joe Taylor's WSPR documentation is that we actually transmit approximately every 10 minutes in this case, but that we randomly choose which 2 minute window in that 10 minutes to transmit.

So, to implement this, I need a couple of time values.  The transmission time calculated from TX Percent and a randomly chosen two minute interval in that timeframe.  The nextSync calculation will need changing to first wait for the randomly chosen period to arrive, transmit the symbol stream and then a wait for the remainder of the time calculated by TX Percent.  The modified code looks like this:

PUB nextSync : s
  s := ROUND(1.0 / TXPercent * 2.0)    ' Calculate when next occurs in minutes
  case interval
    Random:
      s := (||?Rnd // s)               ' Randomize the result
      interval := Calculated           ' Next time use the calculated value
    Calculated:
      s -= (Sync / 60)                 ' Wait the remainder of calculated time
      interval := Random
  s += (s // 2)                        ' Send on a 2 minute boundary
  s *= 60                              ' Convert minutes to seconds

The overall effect of this is going to be to randomize the first transmission start time whilst the second will always land on the calculated TX Percent time slot.  So, every other transmission will be exacly 10 minutes aligned at TX Percent of 20%.

I am not certain this is exactly what I want either, but I will give it a go and see how I like the new effect.  If it does not suit me, I will go with choosing a random slot in the 10 minute window, then waiting until the end of the 10 minute window and choosing a new random slot in the next 10 minute window.  The potential negative on that solution is that we could wait up to 20 minutes if the random generator chose the first 2 minute slot and then chose the last 2 minute slot in the next 10 minute window.  Sort of the opposite problem I currently have.  Anyone have any thoughts on this?

After much ado about nothing, I have settled on the following implementation (as much as anything is ever "settled"):

PUB nextSync : s
  s := ROUND(1.0 / TXPercent * 2.0)    ' Calculate when next occurs in minutes
  if interval++ & 1
    s := (||?Rnd // s) + 1             ' Randomize the result
  s += (s // 2)                        ' Aalways send on a 2 minute boundary
  s *= 60                              ' Convert minutes to seconds

The effect is clear enough.  I randomize every other transmission.  Simple enough and not being such a hog of WSPR bandwidth.  The interval variable is a BYTE value that gets incremented every time we calculate the next transmission time.  The least significant bit determines if we use a  random or calculated next transmission time.

<Insert 3/4 of a day delay here>

So, I have reverted back to a mode where I transmit every N minutes based on TX Percent calculation only.  I decided I really didn't like having the randomizing in there and have commented it out.  There is sufficient randomness of folks using the same TX Percent value starting at different 2 minute timeslots and then carrying on at a consistent period for my liking.  If I find I am syncing with another station that I want to copy, I can delay my start by a time slot and solve the problem that way.  Bit of a wasted exercise, but so be it.