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
