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!
> On May 30, 2015, at 6:26 PM, Joe Taylor <[email protected]> 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<[email protected]> 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 >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> wsjt-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> wsjt-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > ------------------------------------------------------------------------------ > _______________________________________________ > wsjt-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wsjt-devel ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
