On 31/05/2015 02:39, Joe Taylor wrote:
> Hi Bill,
Hi Joe,
>
> I'm not sure I understand exactly what you want to do. Allow more than
> the presently designated 10 bands in the band-hopping schedule? Could
> be OK, I suppose; but it might require abandoning some safeguards on
> band choices that we had.
It was more to integrate with the configuration of working frequencies.
>
> The following is from the WSPR4 online manual at
> http://physics.princeton.edu/pulsar/K1JT/doc/wspr/wspr-main.html
>
> #########################################################################
>
> Coordinated hopping enables a sizable group of stations around the world
> to move together from band to band, thereby maximizing the chances of
> identifying open propagation paths.
>
> Band (m) 160 80 60 40 30 20 17 15 12 10
> UTC Minute 00 02 04 06 08 10 12 14 16 18
> 20 22 24 26 28 30 32 34 36 38
> 40 42 44 46 48 50 52 54 56 58
> The band-selection schedule repeats starting at UTC minutes 20 and 40,
> for a total of three full ten-band sequences in each hour. If the
> designated band for a given time slot has not been checked as active, a
> random choice is made among the active bands. The algorithm for choosing
> whether to receive or transmit guarantees at least one transmission on
> each active band every two hours. If all ten bands are active, up to
> three transmissions may be made on a given band in a two hour period.
> #########################################################################
OK, got it now. I had missed the point about global coordination.
I have checked in some changes to simplify the code in bandHopping() a
little and I am working on a more Qt compatible band list maintenance
for hopping.
Now the band hopping target frequencies are a the intersection of those
assigned to WSPR in the working frequency list, the current active set
from the band hopping settings and the current scheduled band or a
random one from the intersection of the active set and the band hopping
set if the scheduled band is not available.
>
> Because of the screwup at SourceForge you may not have noticed that I
> corrected two WSPR frequencies in FrequencyList.cpp.
Thanks, I had spotted one but not the other :( Apologies to any testers
that ended up on the wrong frequencies.
>
> -- 73, Joe
73
Bill
G4WJS.
>
> On 5/30/2015 8:57 PM, Bill Somerville wrote:
>> On 31/05/2015 01:50, Steven Franke wrote:
>> Hi Steve,
>>> To those playing with WSPR mode in the development branch -
>>> After I committed r5471, while in WSPR mode I played around by cycling
>>> between various buttons, e.g. Monitor/Stop/Enable TX/Halt TX/Tune. There is
>>> apparently at least one combination of button pushes that leaves the
>>> radio’s ptt state out of phase with what it should be… At this point, I
>>> have no reason to think that my bandhopping changes caused this - but you
>>> never know… Fair warning!
>> I doubt your changes have done that, the PTT logical has been prone to
>> glitches when button clicks in some order exceed the timers used to
>> sequence Rx/Tx changeovers.
>>
>> While on the subject of band hopping, I am currently trying to integrate
>> the configuration driven bands and frequencies into the band hopping
>> code. I see a few problems with the band hopping assuming that 10 fixed
>> bands are available, I realize that realistic band hopping activity will
>> most likely feature the specified bands but it would be convenient to
>> make the schedule more dynamic and based on the actual bands for WSPR
>> working frequencies that are set up. Are there any objections to me
>> moving towards that sort of approach?
>>
>> 73
>> Bill
>> G4WJS.
>>>> On May 30, 2015, at 6:26 PM, Joe Taylor<j...@princeton.edu> wrote:
>>>>
>>>> Steve --
>>>>
>>>> SourceForge seems to be having problems; the email notices, at least,
>>>> seem not to be keeping up. But as far as I can see the repository is
>>>> perfectly OK. Please update to r5471 (the latest commit), merge in your
>>>> changes, and recommit. I'd like to try your activation of the
>>>> table-based scheduling for WSPR.
>>>>
>>>> -- Joe, K1JT
>>>>
>>>> On 5/30/2015 1:27 PM, Steven Franke wrote:
>>>>> I'm running a version that uses a modified version of the hopping.f90
>>>>> table to decide when to transmit. I changed hopping.f90 to limit the
>>>>> number of successive tx’s to two. The new mainwindow.cpp calls
>>>>> bandHopping() for both non-hopping and hopping mode in order to decide
>>>>> whether or not to tx. Seems to be working. I tried to commit it, but
>>>>> r5470 must have been committed just before I tried to add my commit, so I
>>>>> got a “commit failed” message. That was some time ago, but I am still
>>>>> unable to view the details of the r5470 commit. It says “Loading commit
>>>>> details…”. When I try to see the files under the “WSJT” tab, I see “No
>>>>> (more) commits”. After googling a bit, I see that this can result when
>>>>> two commits are attempted within too-short of an interval. I hope that I
>>>>> didn’t screw something up...
>>>>>
>>>>> Steve k9an
>>>>>
>>>>>> On May 29, 2015, at 7:38 PM, Joe Taylor<j...@princeton.edu> wrote:
>>>>>>
>>>>>> Hi Steve and all,
>>>>>>
>>>>>> Thanks for committing the tone-frequency patch and for catching the
>>>>>> logical error in the code supposedly guarding against consecutive
>>>>>> transmissions. As you have probably noticed, I've been working mostly on
>>>>>> other things (JT4, etc) -- and I know that WSPR mode still needs some
>>>>>> attention.
>>>>>>
>>>>>> You're right that the frequency-time table computed by hopping.f90 is
>>>>>> not yet being used. I had planned to make "normal" (i.e., randomized)
>>>>>> band-hopping work properly first, and then switch over to using the
>>>>>> coordinated schedule. Please feel free to work on any of this, as you
>>>>>> find time.
>>>>>>
>>>>>> I have found one other peculiarity, just now. With r5466 I'm
>>>>>> band-hopping between just two bands, 15 and 20 meters. I believe the
>>>>>> radio is doing what's requested, and the correct frequencies are being
>>>>>> posted to WSPRnet. But the dividing lines in the decoded text window
>>>>>> between different Rx sequences include some oddball surprises. For
>>>>>> example:
>>>>>>
>>>>>> ------------------------ Transmiting WSPR-2 ----------------------- 15m
>>>>>> ---------------------------------------------------------------------5m
>>>>>> 2310 -26 -0.3 14.097010 1 PA1GVZ JO22 30 5948
>>>>>> 2310 -27 -0.9 14.097016 -1 G4IOG JO01 20 5728
>>>>>> 2310 -23 -0.3 14.097045 -1 W2GNN FN20 0 34
>>>>>> 2310 -10 -0.4 14.097052 0 DF9PV JO30 37 6160
>>>>>> 2310 -18 -1.0 14.097072 -1 VE3JHM EN96 23 855
>>>>>> 2310 -12 -0.4 14.097079 -1 VE3HII FN04 37 584
>>>>>> 2310 -11 -0.9 14.097101 -2 EA6FG JM19 23 6407
>>>>>> 2310 -17 0.6 14.097114 0 K8CT EN83 33 775
>>>>>> 2310 -24 -2.4 14.097123 0 K5OK EM12 37 2175
>>>>>> 2310 -24 -0.4 14.097154 -1 N8SDR EM79 27 888
>>>>>> 2310 -1 -0.2 14.097179 0 DL8EDC JO31 37 6116
>>>>>> -------------------------------------------------------------------33cm
>>>>>> 2312 -25 -0.3 21.096180 0 W8AC EN91 37 549
>>>>>> -------------------------------------------------------------------33cm
>>>>>> 2314 -25 0.4 21.096035 0 G8VDQ IO91 37 5596
>>>>>> 2314 -23 0.1 21.096082 0 M0XDC JO01 37 5728
>>>>>> -------------------------------------------------------------------33cm
>>>>>> 2316 -26 -1.3 21.096080 -1 DL2WB JN39 23 6205
>>>>>> ------------------------ Transmiting WSPR-2 ----------------------- 20m
>>>>>> -------------------------------------------------------------------33cm
>>>>>> 2322 -18 1.4 21.096034 0 G8VDQ IO91 37 5596
>>>>>> 2322 -20 -1.3 21.096079 0 DL2WB JN39 23 6205
>>>>>> 2322 -24 -0.2 21.096180 0 W8AC EN91 37 549
>>>>>> ------------------------ Transmiting WSPR-2 ----------------------- 20m
>>>>>> ---------------------------------------------------------------------5m
>>>>>>
>>>>>> I have no idea where these tags are being incorrectly assigned -- or
>>>>>> where a non-ham-band like "5m" came from. Probably it has something to
>>>>>> do with the changes Bill made to the way frequency/mode combinations are
>>>>>> stored and used, and my code around line 4164 in mainwindow.cpp.
>>>>>>
>>>>>> -- Joe
>>>>>>
>>>>>>
>>>>>> On 5/29/2015 8:04 PM, Steven Franke wrote:
>>>>>>> Bill, Joe and all,
>>>>>>>
>>>>>>> Running r5467 which incorporates Bill’s recent repairs to bandhopping.
>>>>>>>
>>>>>>> Hopping seems to be working, but I have seen 4 successive transmissions
>>>>>>> already after running for only an hour or so. FWIW, I noticed that the
>>>>>>> line of code that should prevent successive transmissions (line 005 in
>>>>>>> the snippet below) depends on mutually exclusive conditions (m_ntr==0
>>>>>>> on line 001 and m_ntr==-1 on line 005) so it will never get a chance
>>>>>>> to kill a second transmission…
>>>>>>>
>>>>>>> 001 if(m_nseq==0 and m_ntr==0) { //Decide whether
>>>>>>> to Tx or Rx
>>>>>>> 002 m_tuneup=false; //This is not an
>>>>>>> ATU tuneup
>>>>>>> 003 if(m_pctx==0) m_nrx=1; //Don't transmit
>>>>>>> if m_pctx=0
>>>>>>> 004 bool btx = m_auto and (m_nrx<=0); //To Tx, we need
>>>>>>> m_auto and Rx sequsnce finished
>>>>>>> 005 if(m_ntr == -1) btx=false; //Normally, no
>>>>>>> two consecutive transmissions
>>>>>>>
>>>>>>> It looks like the transmission matrix that is created in hopping.f90 is
>>>>>>> not being used at the moment. If it’d be easy to switch to using the
>>>>>>> hopping.f90 table to decide when to transmit for both single-band _and_
>>>>>>> hopping cases, I already have a modified version of hopping.f90 that
>>>>>>> trims the hopping table so that there are no more than 3 successive
>>>>>>> transmissions. (I did this before it dawned on me that the table wasn’t
>>>>>>> being used…)
>>>>>>>
>>>>>>> The table that Joe creates in hopping.f90 has a nice property - it
>>>>>>> tries to guarantee that a transmission will occur a certain number of
>>>>>>> times on each band within the 2-hour period covered by the table… That
>>>>>>> property wouldn’t matter (but also wouldn’t hurt) if the table was used
>>>>>>> to decide when to transmit when in single-band mode.
>>>>>>>
>>>>>>> Steve k9an
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
