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
