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
