Hi Bill, 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.
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. ######################################################################### Because of the screwup at SourceForge you may not have noticed that I corrected two WSPR frequencies in FrequencyList.cpp. -- 73, Joe 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 ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
