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 <[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
