On 30/05/2015 18:27, Steven Franke wrote:
Hi Steve,
...
> 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...
The repository is fine, the repository web browser is a bit behind the
curve. I believe SF limit their server load by batching various
processes like updating the Subversion browser and that can result in
transient inconsistent states.
You are probably best off just updating your workspace or if you want to
view other commits then use the svn command line client to view the log
and repository state (or TortoiseSVN or whatever mechanism you use to
access the repository).
>
> Steve k9an
73
Bill
G4WJS.
>
>> On May 29, 2015, at 7:38 PM, Joe Taylor <j...@princeton.edu> 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
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
