On 01/06/2015 13:35, Steven Franke wrote:
Bill, Eric, Joe
Hi Steve,
I think that the way it should work is this — if coordinated band
hopping is selected (which is the only band hopping option for now)
then an active coordinated band will be visited according to the
coordinated schedule that you referenced. Otherwise, a random
selection is made from the list of currently active bands. 630m should
be an allowed member of the set of active bands, as should 6m/2m, etc.
Thus, it should have worked when Eric had band hopping enabled and
630m was the only active band.
That does seem reasonable. Exactly the same occurred to me when I was
looking at the code. The section that picks a"random" band when the
scheduled band is not available (not selected in the current phase
sunrise/day/sunset/night or deleted from the working frequencies i.e.
not available at all) currently does a non-exhaustive random selection
of the rest of the coordinated bands. It would not be hard to extend
this random selection to all the configured bands in the working
frequencies list.
The only issue is that users might be surprised by a band outside of the
coordinated set being chosen and they might be even more surprised it it
were chosen for transmit.
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?
If we are going to stick with this approach, then the logic should
allow for consulting the tx table even if band hopping is off and the
current band is an uncoordinated band…
Steve k9an
73
Bill
G4WJS.
On Jun 1, 2015, at 9:45 AM, Bill Somerville <g4...@classdesign.com
<mailto:g4...@classdesign.com>> wrote:
On 01/06/2015 04:34, Eric NO3M wrote:
Hi Eric,
Testing this evening with Tx Pct 50%, band hopping = false, got 2
consecutive transmissions, but nothing further afterward. After
switching to Band hopping = true, Tx Pct still at 50%, and only "630" in
the Sunrise, Day, et.al., fields, Tx was triggered once and no further
after at least 10 minutes.
Currently WSJT-X only supports coordinated band hopping as specified in
the WSPR manual:
http://physics.princeton.edu/pulsar/K1JT/doc/wspr/wspr-main.html#BANDHOPPING
so only the 10 bands that are globally coordinated are candidates for
band hopping.
73 Eric NO3M / WG2XJM
73
Bill
G4WJS.
On 05/31/2015 04:25 PM, Steven Franke wrote:
What are you using for the grayline bands and duration?
Joe -
Right now I have it set up as follows:
Sunrise: 80 40 30 20 17 15 12 10
Day: 30 20 17 15 12 10
Sunset: 40 30 20 17 15 10
Night: 160 80 40 30 20
Gray Time: 120
On a couple of occasions I’ve felt like the grayline duration was
not working quite right - but I haven’t tried to sort it out yet.
Re the hopping schedule - it still needs sanity checks for cases
where the user requests an impossible set of parameters (e.g. TX
percentage > 67% doesn’t make sense if max # of consecutive
transmissions is 2…). It might be simpler to give the user just a
few “sane” options for max # of transmissions and overal TX percentage…
Steve k9an
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
