Re: [wsjt-devel] New FT8 Frequencies?

[Gary McDuffie]

> On Mar 23, 2018, at 12:50 PM, rjai...@gmail.com wrote:
> 
> How do you know we're running power?

I said nothing about running power.  I said strong signal, wanting to have a 
way to only allow display or decode of weaker signals, the level of which I 
determine and set.  This is similar to the function available in DXpedition 
mode.

Gary - AG0N
--
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] New FT8 Frequencies?

[Tsutsumi Takehiko]

Hi,

I support ZL2iFB Gary’s proposal to setup a  separate small group to discuss 
about default frequencies of wsjt-x from the productiveness.

Regards,

take

de JA5AEA

Sent from Mail for Windows 10

--
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] Callsign highlighting

[Morris Wideman via wsjt-devel]

 This would be a big help to have callsigns color coded, would it also be 
possible to code in filters where some messages are not shown such as other on 
going qso`s that are not necessary to view and even stations that have been 
worked B4. This would de-clutter busy screens that have so many decodes you 
cannot even view them all. I sometimes feel this is why some stations are a 
sequence or two late answering callsthey do not see them they have scrolled out 
of view. These could be an option only if the operator wanted to 
activate.Thanks for your consideration73 wa4mit Morris
On Friday, March 23, 2018, 4:35:57 PM CDT, Alex, VE3NEA 
 wrote:  
 
 Hi Bill,

Thank you for a link to your message aggregator. I will take a closer look at 
it tonight, it looks like it includes a useful 
piece of code for working with the wsjt-x messages.

I included the Delphi project only as a testing tool for the new feature in 
wsjt-x, so please ignore it if it is incomplete.

My C++ code does not change the caret position, the callsign is highlighted 
using a temporary cursor object.

73 Alex VE3NEA



On 2018-03-23 17:14, Bill Somerville wrote:
> On 23/03/2018 20:41, Alex, VE3NEA wrote:
>> I have written some code that allows a UDP server, e.g., a logger, to tell 
>> WSJT-X what background color to use for each 
>> callsign in the Band Activity panel. This might be useful to those who chase 
>> various awards, if the logger assigns different 
>> colors to new IOTA groups, US counties, etc. The end result looks like on 
>> the attached screenshot. The .diff file is here:
>>
>> http://www.dxatlas.com/Misc/callsign_highlight.zip
>>
>> The zip also includes a Delphi class for listening and replying to the 
>> WSJT-X messages, and a demo program that shows how to 
>> use the class, which is also useful for testing the new feature once it is 
>> included in WSJT-X.
>>
>> Please review and merge if OK.
> 
> Hi Alex,
> 
> looks good but I have some issues. Please check out this: 
> https://www.dropbox.com/s/xlvc5kxy85ymtn9/message_aggregator.zip?dl=0 
> , it is a very basic UDP message server application written in Object Pascal 
> and also uses Indy for services. The message 
> cracking routines may be useful to you, free free to copy them - all I 
> require is credit.
> 
> I will look in more detail at your patch, I have a concern about cursor 
> positioning in the decode windows that I need to check.
> 
> There is a requirement to negotiate the message schema number if you intend 
> to send messages back to WSJT-X instances, this is 
> necessary in case a new schema is introduced as the WSJT-X UDP messages are a 
> grid topology and all nodes must agree on the "on 
> the wire" message schema. The schema number is allowed to decrease if an old 
> lower schema node joins the party. The 
> MessageServer.cpp class in the WSJT-X sources does this correctly. See code 
> at line 155 handling Heartbeat messages here: 
> https://sourceforge.net/p/wsjt/wsjt/HEAD/tree/branches/wsjtx/MessageServer.cpp
>  .
> 
> I also have a partial implementation of joining a multicast group for the 
> AutoIt scripting language, this is relevant because it 
> has no built in library support for multicast and it is used to implement the 
> current version of JTAlert, so JTAlert must bind a 
> unicast address for now. If JTAlert is in the grid then it must degrade to a 
> single server (JTAlert) many client (WSJT-X) 
> topology, which excludes other servers :( I need to find time to complete 
> this and offer it to Laurie as a plug in replacement 
> for the AutoIt UDP server module.
> 
> 73
> Bill
> G4WJS.

--
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] Callsign highlighting

[Alex, VE3NEA]

Hi Bill,

Thank you for a link to your message aggregator. I will take a closer look at it tonight, it looks like it includes a useful 
piece of code for working with the wsjt-x messages.


I included the Delphi project only as a testing tool for the new feature in 
wsjt-x, so please ignore it if it is incomplete.

My C++ code does not change the caret position, the callsign is highlighted 
using a temporary cursor object.

73 Alex VE3NEA



On 2018-03-23 17:14, Bill Somerville wrote:

On 23/03/2018 20:41, Alex, VE3NEA wrote:
I have written some code that allows a UDP server, e.g., a logger, to tell WSJT-X what background color to use for each 
callsign in the Band Activity panel. This might be useful to those who chase various awards, if the logger assigns different 
colors to new IOTA groups, US counties, etc. The end result looks like on the attached screenshot. The .diff file is here:


http://www.dxatlas.com/Misc/callsign_highlight.zip

The zip also includes a Delphi class for listening and replying to the WSJT-X messages, and a demo program that shows how to 
use the class, which is also useful for testing the new feature once it is included in WSJT-X.


Please review and merge if OK.


Hi Alex,

looks good but I have some issues. Please check out this: https://www.dropbox.com/s/xlvc5kxy85ymtn9/message_aggregator.zip?dl=0 
, it is a very basic UDP message server application written in Object Pascal and also uses Indy for services. The message 
cracking routines may be useful to you, free free to copy them - all I require is credit.


I will look in more detail at your patch, I have a concern about cursor 
positioning in the decode windows that I need to check.

There is a requirement to negotiate the message schema number if you intend to send messages back to WSJT-X instances, this is 
necessary in case a new schema is introduced as the WSJT-X UDP messages are a grid topology and all nodes must agree on the "on 
the wire" message schema. The schema number is allowed to decrease if an old lower schema node joins the party. The 
MessageServer.cpp class in the WSJT-X sources does this correctly. See code at line 155 handling Heartbeat messages here: 
https://sourceforge.net/p/wsjt/wsjt/HEAD/tree/branches/wsjtx/MessageServer.cpp .


I also have a partial implementation of joining a multicast group for the AutoIt scripting language, this is relevant because it 
has no built in library support for multicast and it is used to implement the current version of JTAlert, so JTAlert must bind a 
unicast address for now. If JTAlert is in the grid then it must degrade to a single server (JTAlert) many client (WSJT-X) 
topology, which excludes other servers :( I need to find time to complete this and offer it to Laurie as a plug in replacement 
for the AutoIt UDP server module.


73
Bill
G4WJS.


--
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] Callsign highlighting

[Bill Somerville]

On 23/03/2018 20:41, Alex, VE3NEA wrote:
I have written some code that allows a UDP server, e.g., a logger, to 
tell WSJT-X what background color to use for each callsign in the Band 
Activity panel. This might be useful to those who chase various 
awards, if the logger assigns different colors to new IOTA groups, US 
counties, etc. The end result looks like on the attached screenshot. 
The .diff file is here:


http://www.dxatlas.com/Misc/callsign_highlight.zip

The zip also includes a Delphi class for listening and replying to the 
WSJT-X messages, and a demo program that shows how to use the class, 
which is also useful for testing the new feature once it is included 
in WSJT-X.


Please review and merge if OK.


Hi Alex,

looks good but I have some issues. Please check out this: 
https://www.dropbox.com/s/xlvc5kxy85ymtn9/message_aggregator.zip?dl=0 , 
it is a very basic UDP message server application written in Object 
Pascal and also uses Indy for services. The message cracking routines 
may be useful to you, free free to copy them - all I require is credit.


I will look in more detail at your patch, I have a concern about cursor 
positioning in the decode windows that I need to check.


There is a requirement to negotiate the message schema number if you 
intend to send messages back to WSJT-X instances, this is necessary in 
case a new schema is introduced as the WSJT-X UDP messages are a grid 
topology and all nodes must agree on the "on the wire" message schema. 
The schema number is allowed to decrease if an old lower schema node 
joins the party. The MessageServer.cpp class in the WSJT-X sources does 
this correctly. See code at line 155 handling Heartbeat messages here: 
https://sourceforge.net/p/wsjt/wsjt/HEAD/tree/branches/wsjtx/MessageServer.cpp 
.


I also have a partial implementation of joining a multicast group for 
the AutoIt scripting language, this is relevant because it has no built 
in library support for multicast and it is used to implement the current 
version of JTAlert, so JTAlert must bind a unicast address for now. If 
JTAlert is in the grid then it must degrade to a single server (JTAlert) 
many client (WSJT-X) topology, which excludes other servers :( I need to 
find time to complete this and offer it to Laurie as a plug in 
replacement for the AutoIt UDP server module.


73
Bill
G4WJS.


--
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

[wsjt-devel] Callsign highlighting

[Alex, VE3NEA]

Hello,

I have written some code that allows a UDP server, e.g., a logger, to tell WSJT-X what background color to use for each callsign 
in the Band Activity panel. This might be useful to those who chase various awards, if the logger assigns different colors to 
new IOTA groups, US counties, etc. The end result looks like on the attached screenshot. The .diff file is here:


http://www.dxatlas.com/Misc/callsign_highlight.zip

The zip also includes a Delphi class for listening and replying to the WSJT-X messages, and a demo program that shows how to use 
the class, which is also useful for testing the new feature once it is included in WSJT-X.


Please review and merge if OK.

73 Alex VE3NEA
--
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] New FT8 Frequencies?

[gary]

OK guys, at the risk of sounding like a cracked record or a corrupted MP3, I’ll 
give this one more shot.

 

Anecdotal reports tell us very little except in your opinions “The FT8 segment 
looks crowded”.  I agree, that is how it LOOKS.  It LOOKS crowded here too … 
and yet we are still making loads of FT8 QSOs with little hard evidence of 
problems due to overcrowding.  Repeatedly re-stating “It looks crowded”, 
sharing busy waterfall snapshots, counting decode rates and telling us it is 
“imperative” to expand the allocation, is getting us nowhere.  

 

In fact, Bill, your comment that you are seeing “nearly 50 decodes every 15 
seconds” when the band is busy tells us it is working just fine as it is.  Your 
own waterfall pic shows all those FT8 signals sharing roughly 2,000 Hz of band. 
 In theory there is room for 40 optimally-spaced 50 Hz wide FT8 signals with no 
overlaps in 2,000 Hz.  The ‘extra’ ~10 decodes you see probably include a few 
outside the 2,000 Hz segment, and others where signals are overlapping. 

 

I often see overlapping signals decoded successfully, sometimes separated by 
just a few Hz and occasionally fully overlapped on exactly the same frequency.  
FT8 does a much better job at separating overlapping signals than we do simply 
by looking at our “overcrowded” waterfalls.  But of course there are limits to 
the magic of FT8.

 

Based on the above, and actual experience every day on the air, I could 
conclude that there is plenty of capacity remaining and no desperate need to 
expand the HF allocations … but what it doesn’t tell us is how many additional 
signals might be present that are not being decoded due to overcrowding, nor 
how the FT8 band occupancy is changing.  If we are not currently experiencing 
severe overcrowding, are we days, weeks, months or years away from that crisis 
point – or will band occupancy automatically level itself out as people shift 
to other less occupied bands and modes?

 

73,

Gary  ZL2iFB 

 

From: Bill Barrett  
Sent: Saturday, 24 March 2018 5:38 a.m.
To: WSJT software development 
Subject: Re: [wsjt-devel] New FT8 Frequencies?

 

This is 20M about noon in Tampa Fl area on a ground mounted vertical. This 
picture is with about 35 decodes every 15 seconds.

During the most active times on 20 & 40M  I can see nearly 50 decodes in 15 
seconds. Imagine Ops with better antennas see even more decodes.

This picture only shows the strongest of signals as well. There could be weaker 
signals under the strong ones.

For those who would like to track stats on the various modes see: 
https://www.pskreporter.info/cgi-bin/pskstats.pl middle of the page.

Activity on FT8 is amazingly higher than any other mode and will only increase 
over time.

Lets see what ultimately happens.

 

Bill W2PKY

 

 

 

 

On Fri, Mar 23, 2018 at 11:07 AM, rjai...@gmail.com   
 > wrote:

I would concede that in Europe it is a problem. My antennas are beamed
to Europe most of the time but there aren't many strong band openings
these days.

I have also heard grumbling among the PSK31 and Olivia crowd that FT8
is interfering with them. They can move but when we move it may cause
conflict. WinLink and Pactor may expand, especially if the new
Technician privilege proposal is approved by the FCC.

So any change has to be considered carefully and with the
understanding that we may just not get what we want.

73
Ria
N2RJ


On Fri, Mar 23, 2018 at 10:15 AM, Andras Bato  > wrote:
> It's only you Ria!
> All FT8 subbands are much too crowded, even in the WARC bands.
> We badly need the higher bands like 21, 24 and 28 MHz but it takes several
> years when
> there will be regular openings on those bands.
> I am terribly surprised when you are living in the USA where there are ARRL,
> IARU HQ,
> and Administrative Council members like K1ZZ and the president is a
> Canadian.
> Is it a problem to ask them for their opinion and propose new band plans
> which would precisely devide e.g. the digital band portions
> to RTTY, PSK, FT8, JT65, JT9 subbands?
> gl de ha6nn
> Andras
>
> On Fri, Mar 23, 2018 at 2:00 PM, rjai...@gmail.com  
>   >
> wrote:
>>
>> I don't think there needs to really be more room. There are several
>> bands that we can use. I prefer to use WARC bands because I have my
>> fill of DX on 20 meters but WARC bands offer additional opportunities.
>> Especially 30 meters where I have gain antennas.
>>
>> 73
>> Ria, N2RJ
>>
>> On Fri, Mar 23, 2018 at 6:51 AM, Andras Bato >  > wrote:
>> > Hi all,
>> > let me repeat a URL which is to be read and someone is to call the
>> > attention
>> > of members of IARU Administrative Council.
>> > 

Re: [wsjt-devel] New FT8 Frequencies?

[rjai...@gmail.com]

How do you know we're running power? I run gain antennas including a 3
element beam at height on 30 meters. I get complaints from some that I
am running excessive power. (I run 50 watts except on 80/160 and 6m
where I will run up to 1500W)

Should I just run a G5RV so as not to bend the needle now?

Ria
N2RJ

On Fri, Mar 23, 2018 at 2:33 PM, Gary McDuffie  wrote:
>
>
>> On Mar 23, 2018, at 2:48 AM, David Alloza  wrote:
>>
>> The concentration of traffic on the narrow 2.5khz (certainly at excessive 
>> power)  causes a significant rise in the noise floor and therefore reduces 
>> the performance of this mode.
>> I think this is something that needs to be considered for the future of 
>> these digital mode.
>
> This brings up a topic I would like to see discussed.  Similar to the 
> DXpedition mode, I would like to see a setting available to either ignore or 
> not even display signals over a certain SNR.  For instance, allow me to say I 
> don’t care about this guy that is bending the needle.  Show me only the ones 
> that are -15 or weaker.  If not a problem, allow ME to set that level for 
> flexibility and band condx.
>
> Gary - AG0N
> --
> 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] New FT8 Frequencies?

[Gary McDuffie]

> On Mar 23, 2018, at 2:48 AM, David Alloza  wrote:
> 
> The concentration of traffic on the narrow 2.5khz (certainly at excessive 
> power)  causes a significant rise in the noise floor and therefore reduces 
> the performance of this mode.
> I think this is something that needs to be considered for the future of these 
> digital mode.

This brings up a topic I would like to see discussed.  Similar to the 
DXpedition mode, I would like to see a setting available to either ignore or 
not even display signals over a certain SNR.  For instance, allow me to say I 
don’t care about this guy that is bending the needle.  Show me only the ones 
that are -15 or weaker.  If not a problem, allow ME to set that level for 
flexibility and band condx.
 
Gary - AG0N
--
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] Monitoring stops suddenly in 1.80 and 1.90 RC2

[Bill Somerville]

On 23/03/2018 16:14, FRANK DB5FP wrote:

Hi Frank,

a couple of clarifications.

The jt9 process does not directly handle audio samples, they are read
and written by a thread of the wsjtx process.

The jt9 process is monitored by the wsjtx process and failures are
reported via a message box including the reason for failure.

If the source of sound samples stops delivering samples; the wsjtx
waterfall and decoding will also stop.

73
Bill
G4WJS.


Hi Bill,

interesting Information, because :

Soundcard has an indicator LED, LED ON means, power ok.
Flashing means data is being read from the soundcard.

And the LED is flashing(all the time)even when waterfall and decode
stopped.
-> wsjtx reads data from soundcard??? but does not pass data to jt9 ???

No Error Messages are generated in wsjtx.

Behavior is the same like I'm pulling USB cord while wsjtx is running->
no message is generated and decode and waterfall is stopped.


Hi Frank,

the general overview is that a thread of the wsjtx process gathers 
incoming audio samples and passes them in chunks to the main UI thread, 
there they are used to drive the Rx level indicator and the waterfall 
graphs. The gathered samples are also accumulated in a shared memory 
buffer and when decoding time arrives (determined by having enough 
samples) the jt9 process is woken from an idle loop to do the decoding. 
Decoding results are passed back to the wsjtx process via the jt9 
sub-process standard output stream.


Your issue could be explained by a USB communications breakdown, the 
flashing LED may not indicate that data is being streamed over USB, just 
that the sound card ADC is active. If the WSJT-X Rx level indicator is 
not showing a level *and* the waterfall stops scrolling, then it is 
fairly certain that the operating system is no longer delivering audio 
samples to the application.


73
Bill
G4WJS.

--
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] Monitoring stops suddenly in 1.80 and 1.90 RC2

[rjai...@gmail.com]

One of my friends has reported something similar - decodes stop for no
reason and start back at random. He doesn't use a Raspberry Pi. He
uses a recent 27" iMac and runs Windows in a Parallels instance. The
rig is a Flex-6300 and uses the COM port for CAT control (via SmartSDR
CAT).

CPU usage seems fine, memory usage seems fine. We have been unable to
pin it down. Audio from the Flex DAX sound card device seems fine too.
Clock is sync'ed.

He's using 1.9.0-rc2 (I'll ask him to upgrade to RC3).

Just a data point.

73
Ria, N2RJ

On Fri, Mar 23, 2018 at 12:14 PM, FRANK DB5FP  wrote:
>
>
>> On 22/03/2018 18:42, FRANK DB5FP wrote:
>> > Hello,
>> >
>> > I'm back with some more Information :
>> >
>> > - the soundcard is not a cheapie:-)  It's a Terratec Aureon
>> > I've used it several years for decoding NOAA sats, without
>> > any notice, even under linux and on RPI2 together with wxtoimg.
>> > - the problem looks like an RPI USB problem.
>> >
>> >I have been searching the internet and found "dwc_otg"
>> >problems.there are many forum entries and debug hints like
>> > kernel command line options etc., but at least nothing will help
>> > solving that usb-driver (that is my conclusion).
>> > - Main problem is of cours that linux-usb handling will loose some
>> >audiodata -> this causes the /usr/bin/JT9 process to stop working
>> >correctly (lower cpu usage than normal), no decode no waterfall
>> >This stops processing audiodata even after a short wile
>> >audiodatat is back again
>> >
>> > --> wsjt-x gui should supervise JT9 process to observe any
>> > irregularities , like it does when JT9 process is shut down
>> > manually.
>> >
>> > 73
>> >
>> > Frank
>> > DB5FP
>>
>> Hi Frank,
>>
>> a couple of clarifications.
>>
>> The jt9 process does not directly handle audio samples, they are read
>> and written by a thread of the wsjtx process.
>>
>> The jt9 process is monitored by the wsjtx process and failures are
>> reported via a message box including the reason for failure.
>>
>> If the source of sound samples stops delivering samples; the wsjtx
>> waterfall and decoding will also stop.
>>
>> 73
>> Bill
>> G4WJS.
>>
> Hi Bill,
>
> interesting Information, because :
>
> Soundcard has an indicator LED, LED ON means, power ok.
> Flashing means data is being read from the soundcard.
>
> And the LED is flashing(all the time)even when waterfall and decode
> stopped.
> -> wsjtx reads data from soundcard??? but does not pass data to jt9 ???
>
> No Error Messages are generated in wsjtx.
>
> Behavior is the same like I'm pulling USB cord while wsjtx is running->
> no message is generated and decode and waterfall is stopped.
>
>
> 73
> Frank
> DB5FP
>
>
>
>
> --
> 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] Monitoring stops suddenly in 1.80 and 1.90 RC2

[FRANK DB5FP]

> On 22/03/2018 18:42, FRANK DB5FP wrote:
> > Hello,
> >
> > I'm back with some more Information :
> >
> > - the soundcard is not a cheapie:-)  It's a Terratec Aureon
> > I've used it several years for decoding NOAA sats, without
> > any notice, even under linux and on RPI2 together with wxtoimg.
> > - the problem looks like an RPI USB problem.
> >
> >I have been searching the internet and found "dwc_otg"
> >problems.there are many forum entries and debug hints like
> > kernel command line options etc., but at least nothing will help
> > solving that usb-driver (that is my conclusion).
> > - Main problem is of cours that linux-usb handling will loose some
> >audiodata -> this causes the /usr/bin/JT9 process to stop working
> >correctly (lower cpu usage than normal), no decode no waterfall
> >This stops processing audiodata even after a short wile
> >audiodatat is back again
> >  
> > --> wsjt-x gui should supervise JT9 process to observe any  
> > irregularities , like it does when JT9 process is shut down
> > manually.
> >
> > 73
> >
> > Frank
> > DB5FP  
> 
> Hi Frank,
> 
> a couple of clarifications.
> 
> The jt9 process does not directly handle audio samples, they are read 
> and written by a thread of the wsjtx process.
> 
> The jt9 process is monitored by the wsjtx process and failures are 
> reported via a message box including the reason for failure.
> 
> If the source of sound samples stops delivering samples; the wsjtx 
> waterfall and decoding will also stop.
> 
> 73
> Bill
> G4WJS.
> 
Hi Bill,

interesting Information, because :

Soundcard has an indicator LED, LED ON means, power ok.
Flashing means data is being read from the soundcard.

And the LED is flashing(all the time)even when waterfall and decode
stopped.
-> wsjtx reads data from soundcard??? but does not pass data to jt9 ???

No Error Messages are generated in wsjtx.

Behavior is the same like I'm pulling USB cord while wsjtx is running->
no message is generated and decode and waterfall is stopped.


73
Frank
DB5FP




--
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] wsjt-devel Digest, Vol 49, Issue 108

[Al Pawlowski]

Finally something reasonable.

And, having side by side channels makes it easier to use the additional space - 
which is what is really needed.

Al Pawlowski, K6AVP
Los Osos, CA USA



> On Mar 22, 2018, at 15:19, wsjt-devel-requ...@lists.sourceforge.net wrote:
> 
> Re: [wsjt-devel] New FT8 Frequencies?
> Message-ID:
>    >
> Content-Type: text/plain; charset="utf-8"
> 
> How about using the JT 9 space since there is almost no one using it

--
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] New FT8 Frequencies?

[rjai...@gmail.com]

I would concede that in Europe it is a problem. My antennas are beamed
to Europe most of the time but there aren't many strong band openings
these days.

I have also heard grumbling among the PSK31 and Olivia crowd that FT8
is interfering with them. They can move but when we move it may cause
conflict. WinLink and Pactor may expand, especially if the new
Technician privilege proposal is approved by the FCC.

So any change has to be considered carefully and with the
understanding that we may just not get what we want.

73
Ria
N2RJ

On Fri, Mar 23, 2018 at 10:15 AM, Andras Bato  wrote:
> It's only you Ria!
> All FT8 subbands are much too crowded, even in the WARC bands.
> We badly need the higher bands like 21, 24 and 28 MHz but it takes several
> years when
> there will be regular openings on those bands.
> I am terribly surprised when you are living in the USA where there are ARRL,
> IARU HQ,
> and Administrative Council members like K1ZZ and the president is a
> Canadian.
> Is it a problem to ask them for their opinion and propose new band plans
> which would precisely devide e.g. the digital band portions
> to RTTY, PSK, FT8, JT65, JT9 subbands?
> gl de ha6nn
> Andras
>
> On Fri, Mar 23, 2018 at 2:00 PM, rjai...@gmail.com 
> wrote:
>>
>> I don't think there needs to really be more room. There are several
>> bands that we can use. I prefer to use WARC bands because I have my
>> fill of DX on 20 meters but WARC bands offer additional opportunities.
>> Especially 30 meters where I have gain antennas.
>>
>> 73
>> Ria, N2RJ
>>
>> On Fri, Mar 23, 2018 at 6:51 AM, Andras Bato  wrote:
>> > Hi all,
>> > let me repeat a URL which is to be read and someone is to call the
>> > attention
>> > of members of IARU Administrative Council.
>> > http://www.iaru.org/administrative-council-meetings.html
>> > I guess it's the high time for them to meet asap!
>> > gl de ha6nn
>> > Andras
>> >
>> > On Fri, Mar 23, 2018 at 8:48 AM, David Alloza  wrote:
>> >>
>> >> Hi,
>> >>
>> >> I would like to add something to the discussion.
>> >>
>> >> At my location (JN25UE) at maximum propagation ( near noon) , the FT8
>> >> band's noise floor on the 30M is 5db higher than on the rest of the 30M
>> >> band.
>> >>
>> >> The concentration of traffic on the narrow 2.5khz (certainly at
>> >> excessive
>> >> power)  causes a significant rise in the noise floor and therefore
>> >> reduces
>> >> the performance of this mode.
>> >>
>> >> I think this is something that needs to be considered for the future of
>> >> these digital mode.
>> >>
>> >> My 73,
>> >>
>> >> David, F4HTQ.
>> >>
>> >>
>> >>
>> >> De : g...@isect.com [mailto:g...@isect.com]
>> >> Envoyé : vendredi 23 mars 2018 00:41
>> >> À : 'WSJT software development'
>> >> Objet : Re: [wsjt-devel] New FT8 Frequencies?
>> >>
>> >>
>> >>
>> >> “There is no doubt that with the super success of the FT8 mode, it is
>> >> imperative that additional frequency “Channels” within each HF band be
>> >> identified for not only the new DXpedition mode, but more importantly
>> >> for
>> >> normal day to day FT8 operations.”
>> >>
>> >>
>> >>
>> >> On the contrary, Rich, it is plainly evident that in normal use we can
>> >> successfully pack in loads of FT8 signals sharing the present fairly
>> >> narrow
>> >> slices of the HF bands.  Don’t get me wrong, I fully support the idea
>> >> of
>> >> monitoring trends and projecting forward but, as things stand, I see
>> >> very
>> >> little hard evidence of an impending crisis.  Just because there are
>> >> few
>> >> obvious clear columns on the waterfall does not mean the band segment
>> >> is
>> >> “full”, since in practice FT8 is extremely good at separating
>> >> overlapping
>> >> signals.  So I refute your assertion that “there is no doubt” that
>> >> additional frequences are needed.  There most certainly is doubt, hence
>> >> I
>> >> disagree that expansion is “imperative”.
>> >>
>> >>
>> >>
>> >> A more scientific way to address issue this would be to gather and
>> >> analyze
>> >> data, objectively, rather than us simply asserting and refuting stuff,
>> >> subjectively.  So what data would be needed?  How would it be gathered
>> >> and
>> >> analyzed?  By whom?  These questions are worth exploring.
>> >>
>> >>
>> >>
>> >> If the data indicate impending crisis, there are other concerns about
>> >> the
>> >> options for avoiding or resolving it.  Aside from the problems
>> >> making/taking/stealing space from other modes to allow for more FT8,
>> >> being
>> >> able to monitor all the FT8 activity on one screen at once is a major
>> >> advantage of the current arrangement, whereas splitting it up across
>> >> additional band segments will make things harder.  It could prove
>> >> counterproductive.
>> >>
>> >>
>> >>
>> >> Having said that, though, I agree there clearly are incompatibilities
>> >> and
>> >> conflicts between normal everyday FT8 activity and the new DXpedition

Re: [wsjt-devel] New FT8 Frequencies?

[George Molnar]

The digital mode watering holes are not (as far as I know in most cases) part 
of any international agreement or national regulation. If a group of operators 
want to agree amongst themselves to operate on a particular spot, it is 
incumbent on them to avoid interference with existing operations and be “good 
neighbors.” Don’t think it is the dev team’s job to dictate slots (and they 
have been extremely thoughtful in this regard).

It seems JT9 and FT8 would be the best fit for side-by-side operation. If the 
FT8 watering hole is crowded where you are, may I suggest that sliding up a 
couple of kHz would be an acceptable practice? In most situations, this will 
leave the JT65 slot open for very weak signal users.

Users can add frequencies to their configurations very easily (see the manual). 
Wide receive passbands are possible on some radios, and who knows, this may be 
a spur to future I/Q stream development, allowing even more bandwidth to be 
guarded at once.


George J Molnar
Washington, DC, USA
KF2T   -   @GJMolnar







--
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] New FT8 Frequencies?

[Andras Bato]

It's only you Ria!
All FT8 subbands are much too crowded, even in the WARC bands.
We badly need the higher bands like 21, 24 and 28 MHz but it takes several
years when
there will be regular openings on those bands.
I am terribly surprised when you are living in the USA where there are
ARRL, IARU HQ,
and Administrative Council members like K1ZZ and the president is a
Canadian.
Is it a problem to ask them for their opinion and propose new band plans
which would precisely devide e.g. the digital band portions
to RTTY, PSK, FT8, JT65, JT9 subbands?
gl de ha6nn
Andras

On Fri, Mar 23, 2018 at 2:00 PM, rjai...@gmail.com 
wrote:

> I don't think there needs to really be more room. There are several
> bands that we can use. I prefer to use WARC bands because I have my
> fill of DX on 20 meters but WARC bands offer additional opportunities.
> Especially 30 meters where I have gain antennas.
>
> 73
> Ria, N2RJ
>
> On Fri, Mar 23, 2018 at 6:51 AM, Andras Bato  wrote:
> > Hi all,
> > let me repeat a URL which is to be read and someone is to call the
> attention
> > of members of IARU Administrative Council.
> > http://www.iaru.org/administrative-council-meetings.html
> > I guess it's the high time for them to meet asap!
> > gl de ha6nn
> > Andras
> >
> > On Fri, Mar 23, 2018 at 8:48 AM, David Alloza  wrote:
> >>
> >> Hi,
> >>
> >> I would like to add something to the discussion.
> >>
> >> At my location (JN25UE) at maximum propagation ( near noon) , the FT8
> >> band's noise floor on the 30M is 5db higher than on the rest of the 30M
> >> band.
> >>
> >> The concentration of traffic on the narrow 2.5khz (certainly at
> excessive
> >> power)  causes a significant rise in the noise floor and therefore
> reduces
> >> the performance of this mode.
> >>
> >> I think this is something that needs to be considered for the future of
> >> these digital mode.
> >>
> >> My 73,
> >>
> >> David, F4HTQ.
> >>
> >>
> >>
> >> De : g...@isect.com [mailto:g...@isect.com]
> >> Envoyé : vendredi 23 mars 2018 00:41
> >> À : 'WSJT software development'
> >> Objet : Re: [wsjt-devel] New FT8 Frequencies?
> >>
> >>
> >>
> >> “There is no doubt that with the super success of the FT8 mode, it is
> >> imperative that additional frequency “Channels” within each HF band be
> >> identified for not only the new DXpedition mode, but more importantly
> for
> >> normal day to day FT8 operations.”
> >>
> >>
> >>
> >> On the contrary, Rich, it is plainly evident that in normal use we can
> >> successfully pack in loads of FT8 signals sharing the present fairly
> narrow
> >> slices of the HF bands.  Don’t get me wrong, I fully support the idea of
> >> monitoring trends and projecting forward but, as things stand, I see
> very
> >> little hard evidence of an impending crisis.  Just because there are few
> >> obvious clear columns on the waterfall does not mean the band segment is
> >> “full”, since in practice FT8 is extremely good at separating
> overlapping
> >> signals.  So I refute your assertion that “there is no doubt” that
> >> additional frequences are needed.  There most certainly is doubt, hence
> I
> >> disagree that expansion is “imperative”.
> >>
> >>
> >>
> >> A more scientific way to address issue this would be to gather and
> analyze
> >> data, objectively, rather than us simply asserting and refuting stuff,
> >> subjectively.  So what data would be needed?  How would it be gathered
> and
> >> analyzed?  By whom?  These questions are worth exploring.
> >>
> >>
> >>
> >> If the data indicate impending crisis, there are other concerns about
> the
> >> options for avoiding or resolving it.  Aside from the problems
> >> making/taking/stealing space from other modes to allow for more FT8,
> being
> >> able to monitor all the FT8 activity on one screen at once is a major
> >> advantage of the current arrangement, whereas splitting it up across
> >> additional band segments will make things harder.  It could prove
> >> counterproductive.
> >>
> >>
> >>
> >> Having said that, though, I agree there clearly are incompatibilities
> and
> >> conflicts between normal everyday FT8 activity and the new DXpedition
> >> fox-n-hounds mode, so I would agree with the suggestion to make more
> space
> >> for DXpedition use, specifically.
> >>
> >>
> >>
> >> I’d therefore like to make a suggestions: how about we designate a
> >> digimode DXpedition zone on each of the HF bands without specifying the
> >> digimode?  That way, the same chunk of band can be used for RTTY, PSK,
> FT8,
> >> JT9, JT65, CW or whatever the DXpeditioners choose, and revert to being
> a
> >> multimode segment when no DXpeditions are using it.  It would be a good
> >> place to experiment with new modes and variants, for instance.
> >>
> >>
> >>
> >> There will still be occasional conflicts if multiple DXpeditions attempt
> >> to use the area at the same time, which suggests they might need to
> slice
> >> the zone more thinly and 

Re: [wsjt-devel] New FT8 Frequencies?

[rjai...@gmail.com]

I don't think there needs to really be more room. There are several
bands that we can use. I prefer to use WARC bands because I have my
fill of DX on 20 meters but WARC bands offer additional opportunities.
Especially 30 meters where I have gain antennas.

73
Ria, N2RJ

On Fri, Mar 23, 2018 at 6:51 AM, Andras Bato  wrote:
> Hi all,
> let me repeat a URL which is to be read and someone is to call the attention
> of members of IARU Administrative Council.
> http://www.iaru.org/administrative-council-meetings.html
> I guess it's the high time for them to meet asap!
> gl de ha6nn
> Andras
>
> On Fri, Mar 23, 2018 at 8:48 AM, David Alloza  wrote:
>>
>> Hi,
>>
>> I would like to add something to the discussion.
>>
>> At my location (JN25UE) at maximum propagation ( near noon) , the FT8
>> band's noise floor on the 30M is 5db higher than on the rest of the 30M
>> band.
>>
>> The concentration of traffic on the narrow 2.5khz (certainly at excessive
>> power)  causes a significant rise in the noise floor and therefore reduces
>> the performance of this mode.
>>
>> I think this is something that needs to be considered for the future of
>> these digital mode.
>>
>> My 73,
>>
>> David, F4HTQ.
>>
>>
>>
>> De : g...@isect.com [mailto:g...@isect.com]
>> Envoyé : vendredi 23 mars 2018 00:41
>> À : 'WSJT software development'
>> Objet : Re: [wsjt-devel] New FT8 Frequencies?
>>
>>
>>
>> “There is no doubt that with the super success of the FT8 mode, it is
>> imperative that additional frequency “Channels” within each HF band be
>> identified for not only the new DXpedition mode, but more importantly for
>> normal day to day FT8 operations.”
>>
>>
>>
>> On the contrary, Rich, it is plainly evident that in normal use we can
>> successfully pack in loads of FT8 signals sharing the present fairly narrow
>> slices of the HF bands.  Don’t get me wrong, I fully support the idea of
>> monitoring trends and projecting forward but, as things stand, I see very
>> little hard evidence of an impending crisis.  Just because there are few
>> obvious clear columns on the waterfall does not mean the band segment is
>> “full”, since in practice FT8 is extremely good at separating overlapping
>> signals.  So I refute your assertion that “there is no doubt” that
>> additional frequences are needed.  There most certainly is doubt, hence I
>> disagree that expansion is “imperative”.
>>
>>
>>
>> A more scientific way to address issue this would be to gather and analyze
>> data, objectively, rather than us simply asserting and refuting stuff,
>> subjectively.  So what data would be needed?  How would it be gathered and
>> analyzed?  By whom?  These questions are worth exploring.
>>
>>
>>
>> If the data indicate impending crisis, there are other concerns about the
>> options for avoiding or resolving it.  Aside from the problems
>> making/taking/stealing space from other modes to allow for more FT8, being
>> able to monitor all the FT8 activity on one screen at once is a major
>> advantage of the current arrangement, whereas splitting it up across
>> additional band segments will make things harder.  It could prove
>> counterproductive.
>>
>>
>>
>> Having said that, though, I agree there clearly are incompatibilities and
>> conflicts between normal everyday FT8 activity and the new DXpedition
>> fox-n-hounds mode, so I would agree with the suggestion to make more space
>> for DXpedition use, specifically.
>>
>>
>>
>> I’d therefore like to make a suggestions: how about we designate a
>> digimode DXpedition zone on each of the HF bands without specifying the
>> digimode?  That way, the same chunk of band can be used for RTTY, PSK, FT8,
>> JT9, JT65, CW or whatever the DXpeditioners choose, and revert to being a
>> multimode segment when no DXpeditions are using it.  It would be a good
>> place to experiment with new modes and variants, for instance.
>>
>>
>>
>> There will still be occasional conflicts if multiple DXpeditions attempt
>> to use the area at the same time, which suggests they might need to slice
>> the zone more thinly and stick to narrowmode digimodes with tighter pileups,
>> or agree amongst themselves some sort of schedule, or simply check that the
>> area is clear before transmitting – standard practice for polite DXers.
>>
>>
>>
>> 73
>>
>> Gary  ZL2iFB
>>
>>
>>
>> PS  This thread is not really about WSJT-X software development, hence we
>> should probably shift over to the other WSJT-X reflector.
>>
>>
>>
>> From: Rich - K1HTV 
>> Sent: Friday, 23 March 2018 10:18 a.m.
>> To: WSJT 
>> Subject: [wsjt-devel] New FT8 Frequencies?
>>
>>
>>
>> As we all know, when bands are open, it is not unusual to find the
>> standard FT8 frequencies packed, end-to-end with stations. The waterfall is
>> full of dozens of QSOs and many more dozens of stations calling others.
>> There is no doubt that with the super success of the FT8 mode, it is
>> imperative 

Re: [wsjt-devel] Ft 8 in Exhibition Mode

[James Shaver]

Hey Jim – happy to post it there if someone has it handy to provide.  

 

Jim S. 

N2ADV

 

From: W4TMO via wsjt-devel [mailto:wsjt-devel@lists.sourceforge.net] 
Sent: Thursday, March 22, 2018 8:44 PM
To: WSJT software development; Richard Stanley
Cc: W4TMO
Subject: Re: [wsjt-devel] Ft 8 in Exhibition Mode

 

There's over 7K members on the Facebook group.  Maybe post upcoming DXpeditions 
under the "Events" heading along with dates and frequency(s) that'll be used.  
The "Events" heading is always at the top (on the left) so users won't have to 
search thru all the postings.

 

Maybe a link to any webpage posted by  DXpedition too.

 

Probably a good idea to go thru periodically and delete events that have passed 
so upcoming events are more evident.

 

73

Jim

 

W4TMO

USAF Retired

 

 

On Thursday, March 22, 2018, 6:51:18 AM EDT, Richard Stanley via wsjt-devel 
 wrote: 

 

 

 

Anybody could see this was going to happen I would be surprised if anybody is 
shocked Smile

 

Richard G7OED

 

From: Ray Jacobs 

Sent: Wednesday, March 21, 2018 10:16 PM

To: wsjt-devel@lists.sourceforge.net 

Subject: [wsjt-devel] Ft 8 in Exhibition Mode

 

You were right they were on the same frequency as regular ft 8 instead of 
another frequency, somehow they will have to announce what frequency they are 
on. But how do they get the word out?

Sent from AOL Mobile Mail

  _  

--
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

 

 


 

 

Virus-free.  

 www.avast.com

--
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] New FT8 Frequencies?

[Andras Bato]

Hi all,
let me repeat a URL which is to be read and someone is to call the
attention of members of IARU Administrative Council.
http://www.iaru.org/administrative-council-meetings.html
I guess it's the high time for them to meet asap!
gl de ha6nn
Andras

On Fri, Mar 23, 2018 at 8:48 AM, David Alloza  wrote:

> Hi,
>
> I would like to add something to the discussion.
>
> At my location (JN25UE) at maximum propagation ( near noon) , the FT8
> band's noise floor on the 30M is 5db higher than on the rest of the 30M
> band.
>
> The concentration of traffic on the narrow 2.5khz (certainly at excessive
> power)  causes a significant rise in the noise floor and therefore reduces
> the performance of this mode.
>
> I think this is something that needs to be considered for the future of
> these digital mode.
>
> My 73,
>
> David, F4HTQ.
>
>
>
> *De :* g...@isect.com [mailto:g...@isect.com]
> *Envoyé :* vendredi 23 mars 2018 00:41
> *À :* 'WSJT software development'
> *Objet :* Re: [wsjt-devel] New FT8 Frequencies?
>
>
>
>- *“There is no doubt that with the super success of the FT8 mode, it
>is imperative that additional frequency “Channels” within each HF band be
>identified for not only the new DXpedition mode, but more importantly for
>normal day to day FT8 operations.”*
>
>
>
> On the contrary, Rich, it is plainly evident that in normal use we can
> successfully pack in *loads* of FT8 signals sharing the present fairly
> narrow slices of the HF bands.  Don’t get me wrong, I fully support the
> idea of monitoring trends and projecting forward but, as things stand, I
> see very little hard evidence of an impending crisis.  Just because there
> are few obvious clear columns on the waterfall does not mean the band
> segment is “full”, since in practice FT8 is extremely good at separating
> overlapping signals.  So I refute your assertion that “there is no doubt”
> that additional frequences are needed.  There most certainly is doubt,
> hence I disagree that expansion is “imperative”.
>
>
>
> A more scientific way to address issue this would be to gather and analyze
> data, objectively, rather than us simply asserting and refuting stuff,
> subjectively.  So what data would be needed?  How would it be gathered and
> analyzed?  By whom?  These questions are worth exploring.
>
>
>
> If the data indicate impending crisis, there are other concerns about the
> options for avoiding or resolving it.  Aside from the problems
> making/taking/stealing space from other modes to allow for more FT8, being
> able to monitor all the FT8 activity on one screen at once is a major
> advantage of the current arrangement, whereas splitting it up across
> additional band segments will make things harder.  It could prove
> counterproductive.
>
>
>
> Having said that, though, I agree there clearly are incompatibilities and
> conflicts between normal everyday FT8 activity and the new DXpedition
> fox-n-hounds mode, so I would agree with the suggestion to make more space
> for DXpedition use, specifically.
>
>
>
> I’d therefore like to make a suggestions: how about we designate a *digimode
> DXpedition zone* on each of the HF bands *without* specifying the
> digimode?  That way, the same chunk of band can be used for RTTY, PSK, FT8,
> JT9, JT65, CW or whatever the DXpeditioners choose, and revert to being a
> multimode segment when no DXpeditions are using it.  It would be a good
> place to experiment with new modes and variants, for instance.
>
>
>
> There will still be occasional conflicts if multiple DXpeditions attempt
> to use the area at the same time, which suggests they might need to slice
> the zone more thinly and stick to narrowmode digimodes with tighter
> pileups, or agree amongst themselves some sort of schedule, or simply check
> that the area is clear before transmitting – standard practice for polite
> DXers.
>
>
>
> 73
>
> Gary  ZL2iFB
>
>
>
> PS  This thread is not really about WSJT-X software development, hence we
> should probably shift over to the other WSJT-X reflector.
>
>
>
> *From:* Rich - K1HTV 
> *Sent:* Friday, 23 March 2018 10:18 a.m.
> *To:* WSJT 
> *Subject:* [wsjt-devel] New FT8 Frequencies?
>
>
>
> *As we all know, when bands are open, it is not unusual to find the
> standard FT8 frequencies packed, end-to-end with stations. The waterfall is
> full of dozens of QSOs and many more dozens of stations calling others.
> There is no doubt that with the super success of the FT8 mode, it is
> imperative that additional frequency “Channels” within each HF band be
> identified for not only the new DXpedition mode, but more importantly for
> normal day to day FT8 operations. Although the number of JT65 users has
> greatly dwindled, there are still many of them using the mode on HF, so
> these frequencies and their JT65 users should be left alone.*
>
>
>
> *The same holds for PSK31 and its army of Hams who like its rag chew
> 

Re: [wsjt-devel] New FT8 Frequencies?

[David Alloza]

Hi,

I would like to add something to the discussion.

At my location (JN25UE) at maximum propagation ( near noon) , the FT8 band's 
noise floor on the 30M is 5db higher than on the rest of the 30M band.

The concentration of traffic on the narrow 2.5khz (certainly at excessive 
power)  causes a significant rise in the noise floor and therefore reduces the 
performance of this mode.

I think this is something that needs to be considered for the future of these 
digital mode.

My 73,

David, F4HTQ.

 

De : g...@isect.com [mailto:g...@isect.com] 
Envoyé : vendredi 23 mars 2018 00:41
À : 'WSJT software development'
Objet : Re: [wsjt-devel] New FT8 Frequencies?

 

*   “There is no doubt that with the super success of the FT8 mode, it is 
imperative that additional frequency “Channels” within each HF band be 
identified for not only the new DXpedition mode, but more importantly for 
normal day to day FT8 operations.”

 

On the contrary, Rich, it is plainly evident that in normal use we can 
successfully pack in loads of FT8 signals sharing the present fairly narrow 
slices of the HF bands.  Don’t get me wrong, I fully support the idea of 
monitoring trends and projecting forward but, as things stand, I see very 
little hard evidence of an impending crisis.  Just because there are few 
obvious clear columns on the waterfall does not mean the band segment is 
“full”, since in practice FT8 is extremely good at separating overlapping 
signals.  So I refute your assertion that “there is no doubt” that additional 
frequences are needed.  There most certainly is doubt, hence I disagree that 
expansion is “imperative”.  

 

A more scientific way to address issue this would be to gather and analyze 
data, objectively, rather than us simply asserting and refuting stuff, 
subjectively.  So what data would be needed?  How would it be gathered and 
analyzed?  By whom?  These questions are worth exploring.

 

If the data indicate impending crisis, there are other concerns about the 
options for avoiding or resolving it.  Aside from the problems 
making/taking/stealing space from other modes to allow for more FT8, being able 
to monitor all the FT8 activity on one screen at once is a major advantage of 
the current arrangement, whereas splitting it up across additional band 
segments will make things harder.  It could prove counterproductive.

 

Having said that, though, I agree there clearly are incompatibilities and 
conflicts between normal everyday FT8 activity and the new DXpedition 
fox-n-hounds mode, so I would agree with the suggestion to make more space for 
DXpedition use, specifically.

 

I’d therefore like to make a suggestions: how about we designate a digimode 
DXpedition zone on each of the HF bands without specifying the digimode?  That 
way, the same chunk of band can be used for RTTY, PSK, FT8, JT9, JT65, CW or 
whatever the DXpeditioners choose, and revert to being a multimode segment when 
no DXpeditions are using it.  It would be a good place to experiment with new 
modes and variants, for instance.

 

There will still be occasional conflicts if multiple DXpeditions attempt to use 
the area at the same time, which suggests they might need to slice the zone 
more thinly and stick to narrowmode digimodes with tighter pileups, or agree 
amongst themselves some sort of schedule, or simply check that the area is 
clear before transmitting – standard practice for polite DXers.

 

73

Gary  ZL2iFB

 

PS  This thread is not really about WSJT-X software development, hence we 
should probably shift over to the other WSJT-X reflector.

 

From: Rich - K1HTV  
Sent: Friday, 23 March 2018 10:18 a.m.
To: WSJT 
Subject: [wsjt-devel] New FT8 Frequencies?

 

As we all know, when bands are open, it is not unusual to find the standard FT8 
frequencies packed, end-to-end with stations. The waterfall is full of dozens 
of QSOs and many more dozens of stations calling others. There is no doubt that 
with the super success of the FT8 mode, it is imperative that additional 
frequency “Channels” within each HF band be identified for not only the new 
DXpedition mode, but more importantly for normal day to day FT8 operations. 
Although the number of JT65 users has greatly dwindled, there are still many of 
them using the mode on HF, so these frequencies and their JT65 users should be 
left alone.

 

The same holds for PSK31 and its army of Hams who like its rag chew 
capabilities that the FT8 and JT65 modes can’t provide. Then there is, on a 
normal weekday, a vast wasteland of the 14.080 to 14.099 RTTY band. When you 
tune across that frequency range during the week, rarely do you hear more than 
a few RTTY signals, while at the same time, packed into 2 KHz, many dozens of 
FT8 stations can be heard working each other. The only times that the RTTY band 
comes alive is during weekend RTTY contests and during DXpeditions to countries 
that RTTY users need to work