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
