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.
The beacon project is back on the front burner. Frankly, one of the reasons that it has been stalled so long is because of the lousy UI performance. The rotary encoder triggers an interrupt so I never lose control turns. However, the display updates are very laggy and the amount of lag varies considerably. I *HATE* laggy UIs and until now have not looked into why. Frankly the I2C LiquidCrystal library was apparently a hasty adaptation of the original LCD library without regard to performance. It was taking more than a dozen I2C commands for a single character to be updated, let alone the additional ones for cursor positioning and the like. Bogus. All bits are written simultaneously now and the lagginess is completely gone. Sweet! Many thanks to Kevin who pointed out the great work by falconfour in a comment to one of my previous posts. Nice to be back on track and re-energized to complete this project.
I spent a lot of time talking to my pal Eldon about UI decisions. I will be making some changes to the value setting library for alpha-numeric fields to see if the new paradigm works a little cleaner for non-numeric fields.
Another concept that we kicked around was the effect of TX percent on multi-band operation for WSPR. Since WSPR frequencies have been cleanly defined for all bands, I am considering having TX percent of 100% mean the beacon will cycle through all bands on each two minute window. A setup UI would be created to allow enable/disable of each of the bands. See my previous post for a list of bands supported by this beacon (all up to and including 6 metres). So, if you truely wanted to send 100% of the time on one band, you would have to disable all other bands as well as setting TX percent to 100%. Otherwise, the beacon would sequence through the list of enabled bands every two minute window. I am interested in feedback on this idea. I think it makes sense to enable this multi-band mode only on TX percent = 100% as otherwise, i would have to completely rethink the meaning of TX percent when multiple bands are enabled.
Also regarding multi-band operation, I plan to make some concession for external low-pass filter selection based on the currently selected band or frequency. Interested in feedback on what this might look like. Some ideas:
- Provide the frequency to an external function that takes care of the magic itself and leave the details up to the implementer.
- Provide an enable bit (or a counter that is decoded by external hardware) that can be used trigger external relays to select an appropriate low pass filter which is set by one of the following:
- The function described in #1 above as implemented by someone else.
- Providing a set of configurable cutoff frequencies for the various external low-pass filters and automatically selecting one as appropriate based on frequency.
- Define one filter per WSPR band and select based on frequency. This is simple, but may be somewhat inappropriate as for example it makes little sense to have separate low pass filters for both 12 and 10 metres where one would suffice.
I have decided to replace my current rotary encoder with a different one from BI Technologies. The Model EN11 rotary encoder is a nice, inexpensive (even in single unit quantities from Mouser) item that adds a push button and detents. My current encoder had no detents and frankly, I prefer having them. If desired, it can be ordered with or without the switch or the detents. I will be using the switch to change the tuning rate rather than a separate push button. See the datasheet here. Thanks to Eldon for providing a sample of this encoder to me to try out with the beacon project.
Eldon and I also revisited the whole topic of what frequency to display on the LCD when in WSPR mode. Most folks that use the great software by Joe Taylor are used to setting the rig display (on 30 metres for example) to 10.138700 MHz and generating tones in the 1400-1600 hz range to feed into your SSB transmitter. The actual transmit frequency can be set by double clicking in the "waterfall" display or by typing it in to the "Tx:" frequency edit box. One idea kicked around was to only display the WSPR band (30 metres, 20 metres, etc) and an offset from the start of the WSPR band. The offset is only 200 hertz total. This sort of makes sense to me, but I have an uneasyness when I don't know precisely what frequency I am transmitting on. Joe Taylor's software shows the exact transmit frequency. For example, if you clicked in the middle of the 30 metre band, it will show 14.140200 in the "Tx:" frequency box. What is not clear to me is precisely what that frequency means since WSPR signals are composed of four separate tone frequencies that are separated by 1.4648 Hz. In the absence of clarity from Joe's documentation, I have chosen to define the transmit frequency like this:
Each symbol is 1.4648 Hz apart and the displayed transmit frequency is mid-way between symbols 1 and 2. Band edge operations need to take this into account if you wish to stay within the defined WSPR frequency range with the entire 6 Hz spectrum occupied by the complete WSPR signal. Anyone have further thoughts or comments on this?
Anyway, it is nice to be back on track and making progress on my beacon again.
