Re: [wsjt-devel] The FT4 Protocol for Digital Contesting

[Brian Dickman]

Grant, I'd respectfully discourage any lower than about .065 for 20/15/10m.
.060 is the standard CW QRP activity frequency for each of those bands, and
.061 to .064 are the standard calling frequencies for CW SOTA activations
in most if not all IARU regions. The majority of the activity centers on
062. Many dedicated chasers monitor 062 throughout the day for mountaintop
portable QRP signals.

73,
Brian AF7MD

On Fri, Apr 26, 2019 at 4:19 AM Grant VK5GR  wrote:

> Joe et al,
>
> A word if I may about frequency choices. Some of those proposed for FT4
> probably leave a bit to be desired. Here are some thoughts to consider:
>
> 80m 3.595 - PROPOSE 3562kHz - 3595 is completely out of band for JA
> completely and into the phone part of the band outside of Region 2. My
> suggestion based on occupancy and proximity to existing digital sub-bands
> is
> something around 3562kHz (at least keeping away from 3560 which is
> sometimes
> a CW QRP frequency). While the IARU band plans currently have digital as
> 3570-3590kHz a case can be made for expanding that - and given other
> restrictions in some countries on 80m, expanding digital down at least 8kHz
> to 3562kHz makes some sense. A case to be made for the IARU - but you can
> "help" their decision by starting to use it anyway. BTW 3600kHz is the
> centre frequency for IARU R3 80m disaster comms - LSB - so FT4 on 3595 USB
> will badly clash with that - another reason not to use 3595.
>
> 40m 7.090 - PROPOSE 7052kHz (inside the digital sub-band) or 7062kHz (just
> above the digital sub-band noting it is heavily used for SSB at least in
> region 3) - 7090 only makes sense in the USA! Many other countries have
> this
> as SSB voice use. The IARU digital segment is (depending on region)
> 7040-7060 or 7040-7060. With 7056 already being used for FT8 F/H mode on a
> fairly regular basis it would make sense to use say 7050 or 7052kHz
> instead.
> Note that 7090 is the designated SSB QRP frequency. I would promote 7050
> for
> FT4. The only reason not to is that the RTTY guys if FT4 and RTTY are in
> the
> same contest might object - but during the contests the RTTY guys spread
> out
> and use anything from 7030 to 7120 anyway in complete disregard of the band
> plans. If they are going to be that unruly then putting FT4 down there
> doesn't seem all that bad.
>
> * 30m / 17m / 12m - should NOT have FT4 allocations at all. FT4 is
> a
> CONTESTING mode and CONTESTING is by global agreement excluded from those
> WRC79 bands!!! *
>
> 20m 14.140 - PROPOSE 14062kHz - the original proposed use of 14140KHz again
> is well outside the digital segments where FT4 belongs. If anything,
> creeping down into 14060-14070 might be considered acceptable despite not
> being in the band plan if the aim was to separate RTTY and FT4 users in the
> same contest. Going high above 14.112 (the acknowledged edge of the global
> 20m digital band plan segment) will be frowned upon. Take a leaf from 80m
> and use 14062kHz - again at least that keeps it away from the CW QRP Centre
> of activity and meets the objective of separating it from RTTY.
>
> 15m 21.140 - PROPOSE 21062kHz - follow 20m and choose 21062kHz - although
> 21140kHz is the first proposed FT4 frequency that fell inside a digital
> subband...
>
> 10m 28.180 - POROPOSE 28062kHz - again follow 20m
>
> 6m 50.318 - PROPOSE somewhere below 50.313 not above. Moving above is just
> moving further into several countries beacon segments. Not likely to get a
> lot of airplay as a international contesting band for FT8 so not as
> critical
> - but my suggestion would be look below 50.313 not above.
>
> For discussion folks.
>
> Regards,
> Grant VK5GR
> WIA Appointee to the IARU Region 3 Band Plan committee
>
>
>
>
> -Original Message-
> From: Joe Taylor [mailto:j...@princeton.edu]
> Sent: Tuesday, 23 April 2019 1:04 AM
> To: WSJT software development
> Subject: [wsjt-devel] The FT4 Protocol for Digital Contesting
>
> To:   WSJT-X users interested in testing FT4
> From: K1JT, K9AN, and G4WJS
>
> Soon after the "FT8 Roundup" held on December 1-2, 2018, we started
> serious work on a faster, more contest-friendly digital mode that can
> compete with RTTY-contesting QSO rates while preserving many of the
> benefits of FT8.  The result is FT4 -- a new digital mode specifically
> designed for radio contesting.
>
> Over the past month a small group of volunteers have been conducting
> on-the-air tests of FT4.  The early tests were very successful and
> helped us to make a number of important design decisions.  We believe
> FT4 has considerable promise for its intended purpose.
>
> We'll soon be ready for testing by a larger group.  If you might be
> interested in participating and offering your considered feedback,
> please read the descriptive document "The FT4 Protocol for Digital
> Contesting", posted here:
> http://physics.princeton.edu/pulsar/k1jt/FT4_Protocol.pdf
>
> We plan to post downloadable installation packages 

Re: [wsjt-devel] Odd Decoding Problem on new Core i5-8250 Laptop - Only decodes perfect when running HDSDR in parallel

[Brian Dickman]

Mike, you might see what you can turn up using this tool. It goes way
beyond the basic windows power management:

https://www.techpowerup.com/download/techpowerup-throttlestop/

Start out by using it in a monitor-only mode, and get a feel for the
C-state levels when you are successfully decoding vs failing. Then play
with the performance level controls in the tool to see if you can coax the
system into working decodes while it is otherwise idle. It feels like your
system is either dropping into deeper C-states when it shouldn't (causing
realtime latency that drops samples), or there's a driver bug that can't
handle the C-state transitions properly, even when they would otherwise be
safe. In either case, artificially forcing less C-states by using this tool
may get you back to working. The cost is a small increase in power
consumption of the CPU.

It's also sometimes possible to change BIOS settings to limit package
C-states; another way to resolve high latency issues at idle. This app is a
bit less invasive than BIOS changes though, and will give better realtime
feedback.

--
Brian AF7MD

On Sat, Jan 12, 2019 at 4:49 PM Mike Lewis  wrote:

> Hi Bill,
>
>
>
> Tried check/unchecking them, no change.  Uninstalled all 3 audio device
> drivers, rebooted, tested, updated 1 of the drivers, tested, no change.
> Running more tests today, quite a few last night.  Does not have to be an
> audio program running to make things decode again, just need CPU load it
> seems now.  Started with audio programs by chance, but moved on to other
> programs like weather and speedtest and solitaire apps to get the CPU over
> 10%.
>
>
>
>- Mike K7MDL
>
>
>
> *From:* Bill Somerville 
> *Sent:* Saturday, January 12, 2019 05:31
> *To:* wsjt-devel@lists.sourceforge.net
> *Subject:* Re: [wsjt-devel] Odd Decoding Problem on new Core i5-8250
> Laptop - Only decodes perfect when running HDSDR in parallel
>
>
>
> On 12/01/2019 06:36, Black Michael via wsjt-devel wrote:
>
> I had a test session with one user who can easily reproduce the audio
> dropouts.  Latency testing shows his system more than capable of handling
> realtime audio.
>
> I got some timings from the dataSink.
>
> The Good plot is a normal/good decode.  One high time period is corrected
> on the next iteration.
>
> The plots show the time intervals between calls to dataSink.
>
>
>
> The Bad plot is when decoding has stopped.  the n_ihsym never gets to 50
> to satisfy the n_ihsym requirement
>
>
>
>   if(m_ihsym == m_hsymStop) {
>
>
>
> Starting another program (most any one) will cause decoding to stop.  Having 
> another audio program start will cause decoding to start succeeding again.  
> So the audio gets stalled periodically and sticks there until something 
> tickles it.
>
>
>
> de Mike W9MDB
>
>
>
> Hi Mike,
>
> did you check the recording device advanced properties? Was the default
> sample rate set to 48000 Hz and did unchecking either or both of the
> "Exclusive Mode" options help?
>
> 73
> Bill
> G4WJS.
> ___
> 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

Re: [wsjt-devel] Log window -cancel button location Windows vs Mac OS

[Brian Dickman]

The ordering correctly honors each platform owners' user interface guidelines.

On Mon, Aug 13, 2018 at 10:01 AM, Jim Byers  wrote:
> Minor irritant when moving back and forth between Windows and Mac OS
>
> The OK button in the log window is in a different position relative to the 
> Cancel button depending on operating system.
> Windows
>
>
>
>
>
> Mac OS
>
>
>
>
>
>
> My preference is the  OK button on the right side.
>
> 73
> Jim
> VE3AJ VE7KAJ
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] FT8 CQ Fox block possible?

[Brian Dickman]

Another "active solution": auto-disengage Fox mode if many decodes are
standard CQs. It's a good indicator that you are sitting on the
standard channel and shouldn't be allowed to call Fox.

--
Brian AF7MD

On Wed, May 9, 2018 at 7:40 AM, Black Michael via wsjt-devel
 wrote:
> There apparently was somebody on 20M FT8 last night in Fox mode from a
> relatively rare location and caused a mess on 14.074.  Everybody though he
> was calling simple CQ but was Fox so wasn't hearing them and users were
> crowding the lower end of 20M trying to get him making even the the
> Fox/Hound exchange problematic.
>
> I don't think we can leave this up to "operator responsibility" as there are
> just too many out there.
>
> So throwing out a few ideas to hopefully open up the discussion
>
> #1 Active solution -- Add a "Fox" setting to the frequency list which is
> hard-coded for the "standard" bands and would prevent enabling Fox or Hound
> mode on those entries with an appropriate message.
> #2 Passive solution -- Detect Fox/Hound messages during decode and don't
> display them at all unless you have the modes enabled.  This would not stop
> older versions from seeing the decoding though.
> #3 Simple solution -- Whenever Fox mode is selected a big warning message
> comes up about band usage.
>
>
> de Mike W9MDB
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel