Hi Bill
Yes that works great
Thanks
Richard m0clz
-Original Message-
From: Bill Somerville
Sent: Saturday, June 06, 2015 3:06 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X: WSPR band hopping and tune up.
On 06/06/2015 14:45, richard stanley wrote:
> Hi
Bill,
>
> Single band WSPR and band hopping WSPR should now be doing what I think
> we have agreed.
Yes, single band operation now seems to work. Thanks!
Steve k9an
--
___
wsj
Joe, I suppose for those who want to use a narrow (e.g. 30 minutes or less)
grayline duration to try to catch a true grayline opening (when the entire path
is aligned along the sunrise/sunset terminator), then it should probably be
D-region sunset. In my case, at 40deg N, I am using 120 minute d
On 06/06/2015 14:54, Joe Taylor wrote:
> Hi Bill, Steve, and all,
Hi Joe,
...
>
> As a placeholder, in the present routine grayline.f90 I defined the
> grayline to be centered at the time when the sun is 50 arc minutes
> (0.8333 deg) below the local horizon. This is normally taken to be the
> tim
---
> From: Bill Somerville
> Sent: Saturday, June 06, 2015 1:13 AM
> To: wsjt-devel@lists.sourceforge.net
> Subject: Re: [wsjt-devel] WSJT-X: WSPR band hopping and tune up.
>
> Hi All,
>
> to all testers of the development WSPR code, I have enhanced the band
> hopping sched
Hi Bill, Steve, and all,
> Remove redundant Fortran function
>
> lib/hopping.f90 has been superceded by C/C++ code except for the call
> to grayline() which is now called directly.
> http://sourceforge.net/p/wsjt/wsjt/5545/
Thanks for all the recent good additions to WSPR-mode functionality.
I
Bill,
>> While you are on a roll, I’ll just mention another wish-list item. We
>> already have a Tx Next button — it would be nice to have a Next Band
>> selector that would override the band-picking algorithm. This could just be
>> a box with up-down arrow to cycle through the bands… This could
, 2015 1:13 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X: WSPR band hopping and tune up.
Hi All,
to all testers of the development WSPR code, I have enhanced the band
hopping scheduling to allow any band to be included in the schedule.
Bands not in the 10 coordinated bands
On 06/06/2015 14:00, Steven Franke wrote:
> Bill,
Hi Steve & All,
>> On Jun 6, 2015, at 10:18 AM, Bill Somerville wrote:
>>
>> On 06/06/2015 05:36, Steven Franke wrote:
>> Hi Steve,
>>> Replying to my own observation — the behavior is more complex than I
>>> realized. I think that the program is
Bill,
> On Jun 6, 2015, at 10:18 AM, Bill Somerville wrote:
>
> On 06/06/2015 05:36, Steven Franke wrote:
> Hi Steve,
>> Replying to my own observation — the behavior is more complex than I
>> realized. I think that the program is actually trying to raise ptt on the
>> Rx-only band, 630m, but
On 06/06/2015 05:36, Steven Franke wrote:
Hi Steve,
> Replying to my own observation — the behavior is more complex than I
> realized. I think that the program is actually trying to raise ptt on the
> Rx-only band, 630m, but a hamlib error message occurs and then seems to cause
> the program to
On 06/06/2015 05:27, Steven Franke wrote:
> Joe, Bill,
Hi Greg & Joe,
>
> I’m confused about this change from r5542 which reverses a change that I had
> done in r5539:
>
> - if (m_auto &&hop_data.tx_next_) {
> +// if (m_auto &&hop_data.tx_next_) {
> + if ( m_auto && next_tx_state(m_pctx) ) {
Replying to my own observation — the behavior is more complex than I realized.
I think that the program is actually trying to raise ptt on the Rx-only band,
630m, but a hamlib error message occurs and then seems to cause the program to
drop Tx Enable. (The radio is a TS-480.) This is consistent
Joe, Bill,
I’m confused about this change from r5542 which reverses a change that I had
done in r5539:
- if (m_auto &&hop_data.tx_next_) {
+// if (m_auto &&hop_data.tx_next_) {
+ if ( m_auto && next_tx_state(m_pctx) ) {
Was this intended? According to Bill’s comments below this would overr
Bill,
I really like what you’ve done with the Band Hopping scheduler!
Before checking any boxes in the active-band scheduler I checked to see if it
would automatically transmit on a single-band (Band Hopping unchecked) that was
not active in the scheduler. No problem! I also noticed that there
Hi Bill,
> Is 40m a band where your auto ATU has to do some work? I suspect that
> the TS-2000 goes busy on the CAT port while it is tuning. It may be that
> Hamlib needs to allow for even more retries than it currently does when
> recovering from this condition.
I don't use the ATU in the TS-200
On 06/06/2015 01:33, Joe Taylor wrote:
> Hi all,
Hi Joe,
...
> I suspect the reason I lost "Tx Enable" last night may be related to the
> occasional Hamlib error messages I'm seeing. For example, my qDebug()
> output for the past few minutes looks like this:
...
> scheduled: "7.038á600 MHz (40m)
Hi all,
Recent code revisions (5540 through 5543) seem to be band-hopping and
transmitting correctly here.
I suspect the reason I lost "Tx Enable" last night may be related to the
occasional Hamlib error messages I'm seeing. For example, my qDebug()
output for the past few minutes looks like
Hi All,
to all testers of the development WSPR code, I have enhanced the band
hopping scheduling to allow any band to be included in the schedule.
Bands not in the 10 coordinated bands will only be scheduled when the
band for the current coordinated slot is not available, in this case all
the
On 05/06/2015 20:54, Steven Franke wrote:
Hi Steve,
> Thanks for those very helpful comments Bill. I’ve fixed up most of the
> badness in r5540. There remains one print to stdout that I’m using to watch
> the evolution of the scheduling array. I’ll take that out pretty soon.
> Otherwise, I think
Thanks for those very helpful comments Bill. I’ve fixed up most of the badness
in r5540. There remains one print to stdout that I’m using to watch the
evolution of the scheduling array. I’ll take that out pretty soon. Otherwise, I
think that I’ve addressed each of your concerns.
Steve k9an
> O
On 05/06/2015 16:41, Steven Franke wrote:
> Bill,
Hi Steve,
>> It is only a small change. If you move the call of next_tx_state() from
>> MainWindow::bandHopping() into WSPRBandHopping::next_hop() just after
>> the call to FC_hopping(). The member variable m_->tx_percent_ tracks the
>> current valu
Bill,
> It is only a small change. If you move the call of next_tx_state() from
> MainWindow::bandHopping() into WSPRBandHopping::next_hop() just after
> the call to FC_hopping(). The member variable m_->tx_percent_ tracks the
> current value of the UI Tx Pct spin box.
>
> Something like:
>
>
On 05/06/2015 15:03, Steven Franke wrote:
> Hi Bill,
Hi Steve,
>
> On Jun 5, 2015, at 8:33 AM, Bill Somerville wrote:
>> The point of call of Steve's new Tx scheduler needs to be moved into the
>> WSPRBandHopping::next_hop() function so that the logic to decide when to
>> tune and to block transmi
Hi Bill,
On Jun 5, 2015, at 8:33 AM, Bill Somerville wrote:
> The point of call of Steve's new Tx scheduler needs to be moved into the
> WSPRBandHopping::next_hop() function so that the logic to decide when to
> tune and to block transmission on Rx only bands can be applied.
> Currently the de
Hi Bill,
> As for the mystery of auto mode being disabled, maybe the runaway
> watchdog triggered somehow. Was there a message box about it?
No. I'm not going to worry about it until I see it happen again.
-- Joe
-
On 05/06/2015 14:21, Joe Taylor wrote:
> Hi John, Steve, Bill, and all,
Hi Joe;
>
> G4KLA wrote:
>> The new hopping schedule page is fine. RX only is helpful.
>> Still studying percent statistics
> Steve's new scheduler seemed to work OK last evening, but overnight
> somehow the "Tx Enable" button
Hi John, Steve, Bill, and all,
G4KLA wrote:
> The new hopping schedule page is fine. RX only is helpful.
> Still studying percent statistics
Steve's new scheduler seemed to work OK last evening, but overnight
somehow the "Tx Enable" button turned itself off?? I never transmitted
after 0702 UTC.
Hi Bill,
The new hopping schedule page is fine. RX only is helpful. Still studying
percent statistics
Clicking on the waterfall display moves the WSPR marker, but does not change
the TX frequency as shown in the box.
Is it intended that frequency changes should only be made by using
Bill,
> Give it a try and see if you can map your new code into the new class.
> Obviously ask here or directly if you need any help understanding any of
> my code or for help with how it might best be extended.
I just checked in WsprTxScheduler.cpp and have it patched in to replace the
schedul
On 04/06/2015 13:29, Joe Taylor wrote:
> Hi Bill,
Hi Joe,
>
> Nice job with the new band-hopping setup window. Much better than my
> quick-and-dirty setup using Tab 4. :-)
Also no code in MainWindow and many less lines to get the same result.
There is more to come. I have an idea for Steve's req
Hi Bill,
Nice job with the new band-hopping setup window. Much better than my
quick-and-dirty setup using Tab 4. :-)
> There was some discussion about picking any random band from the users
> configured bands when the scheduled band is not configured. This is
> potentially tricky because the u
Re: Bill's implementation:
Hi Bill,
Could you please add the ability to select rhe bands for TX. When band
hopping I would like to be able to TX on just some of the bands chosen for
RX, as per John's implementation (because of antenna limitations and/or
local licence conditions).
Thanks to all f
On 04/06/2015 02:28, Steven Franke wrote:
> Hi Bill,
Hi Steve,
>> There was some discussion about picking any random band from the users
>> configured bands when the scheduled band is not configured. This is
>> potentially tricky because the user specified "tune up" is only
>> specified for the 10
Hi Bill,
> There was some discussion about picking any random band from the users
> configured bands when the scheduled band is not configured. This is
> potentially tricky because the user specified "tune up" is only
> specified for the 10 standard hopping bands. It would perhaps be better
> t
Hi Bill,
> My implementation current looks like this:
That looks good - it provides the flexibility that I was looking for...
--- John G4KLA
--
___
wsjt-devel mailing list
On 03/06/2015 19:00, John Nelson wrote:
> Hi Bill,
Hi John,
>
> Is this the type of hot switching you are referring to? (From my WSPR log -
> UDP status output.)
>
> ---
> 14:39:53: Dial: 28124600, Mode: WSPR-2, DX_Call: G4KLA, Report: -15, TX_Mode:
> WSPR-2, TX_Enabled: 1, Transmitting: 0
> 14
Hi Bill,
Is this the type of hot switching you are referring to? (From my WSPR log -
UDP status output.)
---
14:39:53: Dial: 28124600, Mode: WSPR-2, DX_Call: G4KLA, Report: -15, TX_Mode:
WSPR-2, TX_Enabled: 1, Transmitting: 0
14:39:53: Dial: 10138700, Mode: WSPR-2, DX_Call: G4KLA, Report: -15
Hi All,
I am working on re-factoring this to simplify teh MainWindow code a
little and to provide a more robust user interface for band hopping
settings.
There was some discussion about picking any random band from the users
configured bands when the scheduled band is not configured. This is
39 matches
Mail list logo
