No objections, Bill. Sounds great. The main thing that I was trying to preserve
was the ability to plan out the hopping sequence in advance so that the on/off
sequence doesn't have to be "causal". That seems to be the easiest way to
generate a random on/off sequence that will also tx on a given band a certain
number of times per hour.
Steve k9an
> On May 30, 2015, at 7:57 PM, Bill Somerville <g4...@classdesign.com> wrote:
>
>> 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 <j...@princeton.edu> 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<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
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
