Re: [wsjt-devel] DXpedition Mode on 40 Meters?

[Jim Brown]

On 3/26/2018 5:44 PM, Mike Besemer wrote:

Wow… there had been so much good discussion here about avoiding interference to 
other modes, and then this happens.  If nothing else, it’s extremely 
inconsiderate and the discussion on the PSK31 lists is not favorable for FT8.  
I wish the developers would take responsibility for the genie they’ve let out 
of the bottle and either find a way to fix it or get rid of it.

The FT8 crowd would be upset if the shoe were on the other foot.

Mike
WM4B


Hmmm. For many years, every time I look around 7040 I hear PSK31, so I 
thought that was the 40M watering hole. And I'll bet the guys on the 
expedition did too. Remember, it is the DXpedition that chooses 
operating frequencies, NOT the stations that want to work them. If you 
have a complaint, email to the DXpedition pilot would be the place to 
start. And while you're at it, be prepared to suggest where they should 
set up shop that is NOT the standard FT8 frequency, and that won't make 
someone else unhappy.


73, Jim K9YC


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

Thank you very much, Bill! You work very fast. I applied your patch, and the code worked perfectly. I am sure that there will be 
developers who will take full advantage of the callsign color list, and those who will use the Highlight Last mode to have more 
control.


The reason why I want to highlight only the senders' calls is because one can double-click on them and start calling right away, 
while the stations whose calls are on the left side may not even be copyable, and double-clicking on them is not going to start 
a QSO with them. The Highlight Last option allows the server to specify the color for the left hand or the right hand call, or 
for both, and pass either the same or different colors. There is no need to add another option for that.


When I was initially experimenting with callsign highlighting, I painted all instances of the call that appeared after the last 
separator. I searched for "" backwards from the end of the text, then searched forward for the callsign, starting at that 
point. This proved to be unnecessary in the Highlight Last mode, but when this mode is off, you may want to use this method to 
ensure that highlighting does not propagate beyond the point of the band change. Of course, this will work only if separators 
are enabled.


73 Alex VE3NEA


On 2018-03-26 19:34, Bill Somerville wrote:

Hi Alex,

thanks for reviewing the changes. Some comments in line below.

On 26/03/2018 18:23, Alex, VE3NEA wrote:
1. Some developers may prefer to highlight only the senders' callsigns, or at least use different colors depending on the 
callsign position in the message. Your code does not allow this.
I'm not sure this is of great value as the callsign orders swap each period. I expect highlighting to be used either to indicate 
stations of higher value or worked before, either way it doesn't seem to matter which call position is being highlighted. I need 
more convincing on adding a position1/position2 specific highlighting capability.


2. The server may not be running when a call whose status has changed is decoded again, this results in incorrect 
highlighting. If there is no up to date info, it might be better not to highlight at all.
The server does have the option to clear all the highlighting it has requested, of course this does rely on the server making a 
graceful exit. We must also be careful not to disrupt multiple servers, that might be highlighting different calls, although I 
don't see any immediate advantage to doing that, for sure the WSJT-X protocol does not disallow it if multicast group addresses 
are used.


3. When the status of a callsign changes, e.g. because we have worked it, the new colors are applied to all historical data, 
which is incorrect since the call was not a dupe until it was worked.
I see your point although I'm not sure it matters much, working a station is an event in time but what's the harm in 
highlighting all instances of that call as un-needed once it has been captured. Having said that switching bands has a bearing 
here, maybe WSJT-X should forget all highlighting when switching bands, OTOH the server could do that itself too.


All these issues could be fixed by adding an option to the highlight message that tells the client to apply the colors only to 
the last instance of the call and not to add an entry to the list.


That is certainly quite easy to implement and it does add an extra capability. It would certainly facilitate a more dynamic 
approach which I think is your prime goal. The highlighting would still be cleared if a message with invalid colours were passed.


I am a little concerned that only highlighting one instance of a callsign might confuse users, imagine a busy band where message 
scrolls away quickly, I assume you intend to have the server keep highlighting the callsign each time it is seen in a decode and 
therefore keeping the information current.


Here is another patch:

https://www.dropbox.com/s/7slm4oypbc5g8ks/highlight.diff?dl=0

I haven't updated the message_aggregator application to exercise the "last_only" callsign highlight option as I am out of time 
with an early start for work in the morning, but you have that option now.


If you want to reverse out the previous patch then add a -R option to the previous patch command, or simply revert the files in 
svn. A reverse patch must be done with the original patch file so beware that I have used the same file name and overwritten the 
Dropbox file.


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] DXpedition Mode on 40 Meters?

[Mike Besemer]

Wow… there had been so much good discussion here about avoiding interference to 
other modes, and then this happens.  If nothing else, it’s extremely 
inconsiderate and the discussion on the PSK31 lists is not favorable for FT8.  
I wish the developers would take responsibility for the genie they’ve let out 
of the bottle and either find a way to fix it or get rid of it.  

The FT8 crowd would be upset if the shoe were on the other foot.

Mike
WM4B

From: 
Sent: Monday, March 26, 2018 8:39 PM
To: mwbesemer mwbesemer
Subject: Re: [wsjt-devel] DXpedition Mode on 40 Meters?

Yes he is running the DX mode
Gd luck 
On 3/26/2018 7:38 PM, mwbesemer mwbesemer wrote:
Everything from about 7.071 up is useless due to FT8 QRM from stations calling 
7Q7EI. Is he running DXPedition Mode?

Pity people don't listen before they transmit.  If the FT8 crowd wonders why 
other modes hate them, this is the answer.
Mike
WM4B


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

Re: [wsjt-devel] Request for the mod of UDP type 4 message

[F6BHK]

I understand.

Sorry

Cheers

Serge


On 27/03/2018 01:50, Bill Somerville wrote:

Hi Serge,

I understand your approach but unless you are monitoring all modes the 
decodes from WSJT-X alone will not give you enough information to pick 
a clear frequency to transmit on. I still assert that the waterfall is 
the best way to do that. For example if you are on 20m or 40m and 
allow your search for a clear spot to look up to 2700Hz as you 
originally suggested then transmitting on top of a JT65 QSY would not 
be welcome!


73
Bill
G4WJS.

On 27/03/2018 00:35, F6BHK wrote:


Hi Bill,

My server calculates the best Tx frequency for a given QSO using the 
DECODE messages.


My rig is a Flex 5000A connected to a PC that is dedicated to run it. 
That same PC hosts the WSJT-X client that broadcasts UDP messages to 
tell an iMac running my logging program what's happening on the band. 
This equipment is in my shack.


I am with my family and friends in the living room sitting in the 
sofa talking as if I was a "normal" guy (I mean non-ham of course!). 
But I use an iPad to join a multicast group connected to the server. 
The iPad is served with the CQ and QRZ messages from 
countries/zone/counties/grid I have defined as a must-have. I click 
on the one I need as soon as it comes by. From time to time I know 
that I'll lost the hold on my Tx freq, or it'll become inappropriate. 
Our FT8 segment is, from EU, very busy sometimes. But my server 
calculates using the DECODE messages the best Tx Freq to use. AND


AND

It wants to send this Tx DF with the type 4 message corresponding to 
the QSO to initiate. Holy s***, today it can't!


Hope I am clear: I don't want to make a robot from WSJT-X. I am not 
interested in automatic QSO. I just want to sip my pale ale (I spent 
a lot of time in Newcastle) while making FT8 contacts.


Thank you for your feedback and goodwill.

Cheers

Serge


On 27/03/2018 00:56, Bill Somerville wrote:

Hi Serge,

all you need do is leave "Hold Tx Freq" checked and SHIFT+click on 
the waterfall in a clear spot, you only need to do this once or 
until you loose your clear frequency. Where is a better place to 
choose a good Tx frequency other than the WSJT-X waterfall?


73
Bill
G4WJS.

On 26/03/2018 23:50, F6BHK wrote:

Good evening Bill,

Sorry I don't buy your argument: should I have to prepare my QSO on 
the WSJT-X client (in order to use the Hold Tx Freq and to input 
the Tx DF value on the client) I don't need a UDP type 4 message 
any more: I use my keyboard and that's it.


My need for a modified type 4 is driven by the opportunity to 
initiate the QSO remotely. This is why the type 4 message is 
precious... but I find it incomplete: it should, I believe, permit 
the user to choose the DF for a split.


Please reconsider

Cheers

Serge


On 27/03/2018 00:09, Bill Somerville wrote:

On 25/03/2018 23:35, F6BHK wrote:


I wish I could specify a DF for TX with the UDP type 4 messsage 
different from that of the DECODE message.


Rational behind this request is:

- When I prepare a response to a CQ, I have to check whether the 
freq used for TX is clear or busy. When busy, it is strongly 
recommended to choose a clearer one within the 2.7 KHz bandwidth 
to avoid QRM.


- The most accepted FT8 operating procedures (by ZL2IFB - The FT8 
operating Guide) specify that the best way to go is using split 
mode, and that makes sensesince the FT8 quarter seems to be more 
and more crowded with the growing success of this mode.


I think that allowing the DF TX field in the message of type 4 to 
be different from that of the original CQ would make the 
initiation of a response to a decode message in line with our 
accepted operating procedures and participate to the limitation 
of the QRM.



Listening...

Cheers

Serge 


Hi Serge,

the "Hold Tx "Freq" check box on the WSJT-X main window already 
fills this requirement.


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


--

73, de Serge
F6BHK, ex-VR2LL, G5BHT, FM5GC
PUY SAINT MARTIN, 26 DROME, FRANCE
JN24LP

--
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] Request for the mod of UDP type 4 message

[Bill Somerville]

Hi Serge,

I understand your approach but unless you are monitoring all modes the 
decodes from WSJT-X alone will not give you enough information to pick a 
clear frequency to transmit on. I still assert that the waterfall is the 
best way to do that. For example if you are on 20m or 40m and allow your 
search for a clear spot to look up to 2700Hz as you originally suggested 
then transmitting on top of a JT65 QSY would not be welcome!


73
Bill
G4WJS.

On 27/03/2018 00:35, F6BHK wrote:


Hi Bill,

My server calculates the best Tx frequency for a given QSO using the 
DECODE messages.


My rig is a Flex 5000A connected to a PC that is dedicated to run it. 
That same PC hosts the WSJT-X client that broadcasts UDP messages to 
tell an iMac running my logging program what's happening on the band. 
This equipment is in my shack.


I am with my family and friends in the living room sitting in the sofa 
talking as if I was a "normal" guy (I mean non-ham of course!). But I 
use an iPad to join a multicast group connected to the server. The 
iPad is served with the CQ and QRZ messages from 
countries/zone/counties/grid I have defined as a must-have. I click on 
the one I need as soon as it comes by. From time to time I know that 
I'll lost the hold on my Tx freq, or it'll become inappropriate. Our 
FT8 segment is, from EU, very busy sometimes. But my server calculates 
using the DECODE messages the best Tx Freq to use. AND


AND

It wants to send this Tx DF with the type 4 message corresponding to 
the QSO to initiate. Holy s***, today it can't!


Hope I am clear: I don't want to make a robot from WSJT-X. I am not 
interested in automatic QSO. I just want to sip my pale ale (I spent a 
lot of time in Newcastle) while making FT8 contacts.


Thank you for your feedback and goodwill.

Cheers

Serge


On 27/03/2018 00:56, Bill Somerville wrote:

Hi Serge,

all you need do is leave "Hold Tx Freq" checked and SHIFT+click on 
the waterfall in a clear spot, you only need to do this once or until 
you loose your clear frequency. Where is a better place to choose a 
good Tx frequency other than the WSJT-X waterfall?


73
Bill
G4WJS.

On 26/03/2018 23:50, F6BHK wrote:

Good evening Bill,

Sorry I don't buy your argument: should I have to prepare my QSO on 
the WSJT-X client (in order to use the Hold Tx Freq and to input the 
Tx DF value on the client) I don't need a UDP type 4 message any 
more: I use my keyboard and that's it.


My need for a modified type 4 is driven by the opportunity to 
initiate the QSO remotely. This is why the type 4 message is 
precious... but I find it incomplete: it should, I believe, permit 
the user to choose the DF for a split.


Please reconsider

Cheers

Serge


On 27/03/2018 00:09, Bill Somerville wrote:

On 25/03/2018 23:35, F6BHK wrote:


I wish I could specify a DF for TX with the UDP type 4 messsage 
different from that of the DECODE message.


Rational behind this request is:

- When I prepare a response to a CQ, I have to check whether the 
freq used for TX is clear or busy. When busy, it is strongly 
recommended to choose a clearer one within the 2.7 KHz bandwidth 
to avoid QRM.


- The most accepted FT8 operating procedures (by ZL2IFB - The FT8 
operating Guide) specify that the best way to go is using split 
mode, and that makes sensesince the FT8 quarter seems to be more 
and more crowded with the growing success of this mode.


I think that allowing the DF TX field in the message of type 4 to 
be different from that of the original CQ would make the 
initiation of a response to a decode message in line with our 
accepted operating procedures and participate to the limitation of 
the QRM.



Listening...

Cheers

Serge 


Hi Serge,

the "Hold Tx "Freq" check box on the WSJT-X main window already 
fills this requirement.


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] DXpedition Mode on 40 Meters?

[mwbesemer mwbesemer]

 
  Everything from about 7.071 up is useless due to FT8 QRM from stations calling 7Q7EI. Is he running DXPedition Mode?
  
  Pity people don't listen before they transmit.  If the FT8 crowd wonders why other modes hate them, this is the answer.
  MikeWM4B
 


--
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] Request for the mod of UDP type 4 message

[F6BHK]

Hi Bill,

My server calculates the best Tx frequency for a given QSO using the 
DECODE messages.


My rig is a Flex 5000A connected to a PC that is dedicated to run it. 
That same PC hosts the WSJT-X client that broadcasts UDP messages to 
tell an iMac running my logging program what's happening on the band. 
This equipment is in my shack.


I am with my family and friends in the living room sitting in the sofa 
talking as if I was a "normal" guy (I mean non-ham of course!). But I 
use an iPad to join a multicast group connected to the server. The iPad 
is served with the CQ and QRZ messages from countries/zone/counties/grid 
I have defined as a must-have. I click on the one I need as soon as it 
comes by. From time to time I know that I'll lost the hold on my Tx 
freq, or it'll become inappropriate. Our FT8 segment is, from EU, very 
busy sometimes. But my server calculates using the DECODE messages the 
best Tx Freq to use. AND


AND

It wants to send this Tx DF with the type 4 message corresponding to the 
QSO to initiate. Holy s***, today it can't!


Hope I am clear: I don't want to make a robot from WSJT-X. I am not 
interested in automatic QSO. I just want to sip my pale ale (I spent a 
lot of time in Newcastle) while making FT8 contacts.


Thank you for your feedback and goodwill.

Cheers

Serge


On 27/03/2018 00:56, Bill Somerville wrote:

Hi Serge,

all you need do is leave "Hold Tx Freq" checked and SHIFT+click on the 
waterfall in a clear spot, you only need to do this once or until you 
loose your clear frequency. Where is a better place to choose a good 
Tx frequency other than the WSJT-X waterfall?


73
Bill
G4WJS.

On 26/03/2018 23:50, F6BHK wrote:

Good evening Bill,

Sorry I don't buy your argument: should I have to prepare my QSO on 
the WSJT-X client (in order to use the Hold Tx Freq and to input the 
Tx DF value on the client) I don't need a UDP type 4 message any 
more: I use my keyboard and that's it.


My need for a modified type 4 is driven by the opportunity to 
initiate the QSO remotely. This is why the type 4 message is 
precious... but I find it incomplete: it should, I believe, permit 
the user to choose the DF for a split.


Please reconsider

Cheers

Serge


On 27/03/2018 00:09, Bill Somerville wrote:

On 25/03/2018 23:35, F6BHK wrote:


I wish I could specify a DF for TX with the UDP type 4 messsage 
different from that of the DECODE message.


Rational behind this request is:

- When I prepare a response to a CQ, I have to check whether the 
freq used for TX is clear or busy. When busy, it is strongly 
recommended to choose a clearer one within the 2.7 KHz bandwidth to 
avoid QRM.


- The most accepted FT8 operating procedures (by ZL2IFB - The FT8 
operating Guide) specify that the best way to go is using split 
mode, and that makes sensesince the FT8 quarter seems to be more 
and more crowded with the growing success of this mode.


I think that allowing the DF TX field in the message of type 4 to 
be different from that of the original CQ would make the initiation 
of a response to a decode message in line with our accepted 
operating procedures and participate to the limitation of the QRM.



Listening...

Cheers

Serge 


Hi Serge,

the "Hold Tx "Freq" check box on the WSJT-X main window already 
fills this requirement.


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


--

73, de Serge
F6BHK, ex-VR2LL, G5BHT, FM5GC
PUY SAINT MARTIN, 26 DROME, FRANCE
JN24LP

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

Hi Alex,

thanks for reviewing the changes. Some comments in line below.

On 26/03/2018 18:23, Alex, VE3NEA wrote:
1. Some developers may prefer to highlight only the senders' 
callsigns, or at least use different colors depending on the callsign 
position in the message. Your code does not allow this.
I'm not sure this is of great value as the callsign orders swap each 
period. I expect highlighting to be used either to indicate stations of 
higher value or worked before, either way it doesn't seem to matter 
which call position is being highlighted. I need more convincing on 
adding a position1/position2 specific highlighting capability.


2. The server may not be running when a call whose status has changed 
is decoded again, this results in incorrect highlighting. If there is 
no up to date info, it might be better not to highlight at all.
The server does have the option to clear all the highlighting it has 
requested, of course this does rely on the server making a graceful 
exit. We must also be careful not to disrupt multiple servers, that 
might be highlighting different calls, although I don't see any 
immediate advantage to doing that, for sure the WSJT-X protocol does not 
disallow it if multicast group addresses are used.


3. When the status of a callsign changes, e.g. because we have worked 
it, the new colors are applied to all historical data, which is 
incorrect since the call was not a dupe until it was worked.
I see your point although I'm not sure it matters much, working a 
station is an event in time but what's the harm in highlighting all 
instances of that call as un-needed once it has been captured. Having 
said that switching bands has a bearing here, maybe WSJT-X should forget 
all highlighting when switching bands, OTOH the server could do that 
itself too.


All these issues could be fixed by adding an option to the highlight 
message that tells the client to apply the colors only to the last 
instance of the call and not to add an entry to the list.


That is certainly quite easy to implement and it does add an extra 
capability. It would certainly facilitate a more dynamic approach which 
I think is your prime goal. The highlighting would still be cleared if a 
message with invalid colours were passed.


I am a little concerned that only highlighting one instance of a 
callsign might confuse users, imagine a busy band where message scrolls 
away quickly, I assume you intend to have the server keep highlighting 
the callsign each time it is seen in a decode and therefore keeping the 
information current.


Here is another patch:

https://www.dropbox.com/s/7slm4oypbc5g8ks/highlight.diff?dl=0

I haven't updated the message_aggregator application to exercise the 
"last_only" callsign highlight option as I am out of time with an early 
start for work in the morning, but you have that option now.


If you want to reverse out the previous patch then add a -R option to 
the previous patch command, or simply revert the files in svn. A reverse 
patch must be done with the original patch file so beware that I have 
used the same file name and overwritten the Dropbox file.


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] Request for the mod of UDP type 4 message

[Bill Somerville]

Hi Serge,

all you need do is leave "Hold Tx Freq" checked and SHIFT+click on the 
waterfall in a clear spot, you only need to do this once or until you 
loose your clear frequency. Where is a better place to choose a good Tx 
frequency other than the WSJT-X waterfall?


73
Bill
G4WJS.

On 26/03/2018 23:50, F6BHK wrote:

Good evening Bill,

Sorry I don't buy your argument: should I have to prepare my QSO on 
the WSJT-X client (in order to use the Hold Tx Freq and to input the 
Tx DF value on the client) I don't need a UDP type 4 message any more: 
I use my keyboard and that's it.


My need for a modified type 4 is driven by the opportunity to initiate 
the QSO remotely. This is why the type 4 message is precious... but I 
find it incomplete: it should, I believe, permit the user to choose 
the DF for a split.


Please reconsider

Cheers

Serge


On 27/03/2018 00:09, Bill Somerville wrote:

On 25/03/2018 23:35, F6BHK wrote:


I wish I could specify a DF for TX with the UDP type 4 messsage 
different from that of the DECODE message.


Rational behind this request is:

- When I prepare a response to a CQ, I have to check whether the 
freq used for TX is clear or busy. When busy, it is strongly 
recommended to choose a clearer one within the 2.7 KHz bandwidth to 
avoid QRM.


- The most accepted FT8 operating procedures (by ZL2IFB - The FT8 
operating Guide) specify that the best way to go is using split 
mode, and that makes sensesince the FT8 quarter seems to be more and 
more crowded with the growing success of this mode.


I think that allowing the DF TX field in the message of type 4 to be 
different from that of the original CQ would make the initiation of 
a response to a decode message in line with our accepted operating 
procedures and participate to the limitation of the QRM.



Listening...

Cheers

Serge 


Hi Serge,

the "Hold Tx "Freq" check box on the WSJT-X main window already fills 
this requirement.


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] Request for the mod of UDP type 4 message

[F6BHK]

Good evening Bill,

Sorry I don't buy your argument: should I have to prepare my QSO on the 
WSJT-X client (in order to use the Hold Tx Freq and to input the Tx DF 
value on the client) I don't need a UDP type 4 message any more: I use 
my keyboard and that's it.


My need for a modified type 4 is driven by the opportunity to initiate 
the QSO remotely. This is why the type 4 message is precious... but I 
find it incomplete: it should, I believe, permit the user to choose the 
DF for a split.


Please reconsider

Cheers

Serge


On 27/03/2018 00:09, Bill Somerville wrote:

On 25/03/2018 23:35, F6BHK wrote:


I wish I could specify a DF for TX with the UDP type 4 messsage 
different from that of the DECODE message.


Rational behind this request is:

- When I prepare a response to a CQ, I have to check whether the freq 
used for TX is clear or busy. When busy, it is strongly recommended 
to choose a clearer one within the 2.7 KHz bandwidth to avoid QRM.


- The most accepted FT8 operating procedures (by ZL2IFB - The FT8 
operating Guide) specify that the best way to go is using split mode, 
and that makes sensesince the FT8 quarter seems to be more and more 
crowded with the growing success of this mode.


I think that allowing the DF TX field in the message of type 4 to be 
different from that of the original CQ would make the initiation of a 
response to a decode message in line with our accepted operating 
procedures and participate to the limitation of the QRM.



Listening...

Cheers

Serge 


Hi Serge,

the "Hold Tx "Freq" check box on the WSJT-X main window already fills 
this requirement.


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


--

73, de Serge
F6BHK, ex-VR2LL, G5BHT, FM5GC
PUY SAINT MARTIN, 26 DROME, FRANCE
JN24LP


--
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] Request for the mod of UDP type 4 message

[Bill Somerville]

On 25/03/2018 23:35, F6BHK wrote:


I wish I could specify a DF for TX with the UDP type 4 messsage 
different from that of the DECODE message.


Rational behind this request is:

- When I prepare a response to a CQ, I have to check whether the freq 
used for TX is clear or busy. When busy, it is strongly recommended to 
choose a clearer one within the 2.7 KHz bandwidth to avoid QRM.


- The most accepted FT8 operating procedures (by ZL2IFB - The FT8 
operating Guide) specify that the best way to go is using split mode, 
and that makes sensesince the FT8 quarter seems to be more and more 
crowded with the growing success of this mode.


I think that allowing the DF TX field in the message of type 4 to be 
different from that of the original CQ would make the initiation of a 
response to a decode message in line with our accepted operating 
procedures and participate to the limitation of the QRM.



Listening...

Cheers

Serge 


Hi Serge,

the "Hold Tx "Freq" check box on the WSJT-X main window already fills 
this requirement.


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

[Daniel Ekman]

The USB hardware on the Pi, all versions afaik, is kind of lacking. I've
had lots of problems running SDR's, ranging from rtl-sdr, funcube to hackrf
etc. No HF involved at all, not even located in the shack. They all had
stability issues that cause the data to be halted for some reason. Tested
mostly with gqrx. Some of the problems sounded like a usb hub could
relieve, I didn't have one at the time but read that this could have an
effect as well as kernels/parameters.
Of course, software cannot fix hardware problems, but perhaps detect issues
and retry the connection to see if it comes alive. Would it be possible to
count lost samples and reconnect ? Or is this already in the code (monitor
off) ?
--
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,

I applied your patch to WSJT-X and changed my UDP server to send two QColor parameters, everything works fine. However, there 
are a few issues due to storing the list of highlighted calls.


1. Some developers may prefer to highlight only the senders' callsigns, or at least use different colors depending on the 
callsign position in the message. Your code does not allow this.


2. The server may not be running when a call whose status has changed is decoded again, this results in incorrect highlighting. 
If there is no up to date info, it might be better not to highlight at all.


3. When the status of a callsign changes, e.g. because we have worked it, the new colors are applied to all historical data, 
which is incorrect since the call was not a dupe until it was worked.


All these issues could be fixed by adding an option to the highlight message that tells the client to apply the colors only to 
the last instance of the call and not to add an entry to the list.


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

[FRANK DB5FP]

So 'm   back with some more information.


It's not a HF related issue, it never occurred during TX(everything is
proper grounded, shielded cables etc. ), only during RX.

Sometimes I get an error message like "Data not feed to soundcard
fast enough"(during TX). But this does not stop the decode process nor
the waterfall.

I've been testing with some kernel parameters, these problems are
Raspberry Pi related. One can effect the acceleration of different USB
types (iso or asynchronous, interrupt etc.), since then I did not see
this problem so often.

But there should be a better error handling between different modules
of wstjx. I can not trace the problem because no debug data is
available.


During my test I found something interesting for other Raspberry Pi
or SBC users. All data, during program execution, is written to /tmp.
This is a big problem because /tmp is part of the root- filesystems and
this is located on a sdcard. This stresses sdcard over normal use ->
 defect.
So one has to use a tmpfilesystem to store everything in RAM (how
big???) or on adiffertent storage location. Because I did not find any
config file to specify the /tmp location.


73
Frank
DB5FP 
  


> I had this if I used more than 5 watts on 40mtrs, it used to knock
> the cat control out as well (ic-9100). Bought a decent screened USB
> lead and no issues now. I assume the RF is still there but it is no
> longer picked up. It is funny that we spend a fortune on radio and
> antenna but use the USB lead from a pound shop.
> 
> Richard G7OED
> 
> From: Black Michael via wsjt-devel 
> Sent: Saturday, March 24, 2018 12:34 PM
> To: wsjt-devel@lists.sourceforge.net 
> Cc: Black Michael 
> Subject: Re: [wsjt-devel] Monitoring stops suddenly in 1.80 and 1.90
> RC2
> 
> That sounds like your audio stream froze.
> Possible causes:
> 
> #1 RF in the shack.  
> #2 USB going to sleep -- this should only happen if PC is left
> unattended.
> 
> This is happening while your operating, right?  In that case RF is
> the likely culprit.  Does happen when you transmit? Lots of potential
> sources can cause this, USB cables, ethernet cables, computer cards.
> We had one guy whose rotor caused it even though it wasn't plugged
> into anything but power.
> 
> 
> de Mike W9MDB
> 
> 
> 
> 
> 
> On Saturday, March 24, 2018, 3:35:53 AM CDT, FRANK DB5FP
>  wrote: 
> 
> 
> 
> >   
> 
> Hi Bill,
> 
> 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.  
> 
> The indicator is showing a level but it's not moving and the
> progessbar(15sec.) is still moving. 
> 
> 73s
> 
> 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
> 
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus


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

Iztok Saje for President! :D
Well done Iztok!
All problems solved.
Each IARU official is to resign at once!
gl de ha6nn
Andras

On Mon, Mar 26, 2018 at 1:09 PM, Iztok Saje  wrote:

> Hello!
>
> Summary: Do not over regulate HAM bands!
> Please emphasize in doccumantation:
> "FT8 frequencies are recommendation, not Law".
>
> Few different ideas for "FT8 frequencies" discussion.
>
> 1. Fresh from CQ WPX SSB.
>
> On 80 m, somebody kept telling people calling CQ below 3700:
> "This frequency is not for contest, please QSY, read IARU bla bla ...".
>
> On the other hand: on 160 m, there was no FT8 for 48 hours.
> And some CW was lost in first few kHz (QRMed by non-HAM QRM anyhow).
> Whole first 100 kHz was SSB.
> 5 minutes after contest, FT8 activity is restarted.
>
> It was similar with RTTY contests: FT8 traffic declined and moved to 7 MHz
> (where FT8 is in the "SSB" part) and WARC.
>
> The other day somenone on 40m kept sending beacon (FT8 beacon) saying
> "This is JT65, not FT8"
> AT the same time, no JT65 signals was heard, and FT8 was crowded.
>
> 2. Shared space
> is nice approach https://en.wikipedia.org/wiki/Shared_space ,
> reinvented by https://en.wikipedia.org/wiki/Hans_Monderman .
> (I recall traffic in Kairo: I would not dare to drive, but everything run
> smoothly).
> Concept is simple: by over regulation (Traffic signs, lights, zebras ...)
> drivers rely on signs,
> ignore other drivers and several crashes are due to "It is my right to be
> there").
> By removing signs, drivers start to observe and respect others. Less
> accidents, higher throughput.
>
>
> 3. HAM bands are shared space from day 1
>
> I see HAM bands as shared space. Yes, I did CW QSOs on "SSB" part. Yes, I
> used FT8 outside preferred FT8 2 kHz.
> Yes, I was using RTTY on JT65 subband.
> Yes, I do QSY if there is major contest going on.
>
>
> Any FT8/JT65/JT9/PSK/name_it allocation is just recommendation.
> It is frequency where it is most likely to find some activity.
> No more, no less. And it should be like this.
> All digital modes equal.
>
> 4. HAM spirit
> With respect to others, it is easy to find place for everyone.
> More FT8: FT8 expands. More RTTY: FT8 shrinks.
> Less PSK: sorry, it is not fair to keep 2 kHz empty while FT8 is suffering.
>
> I recall when first 10 kHz on 7 MHz was DX reserved. There is good reason
> why it is no more.
>
> Of course, we have different people on the bands: whatever I do, somebody
> does not like.
> But those people will always find something to dislike and some mission on
> the bands.
>
> 5. current practice
> Yes, we tend to go up. My RX bandwidth is 3.4 kHz. And TX as well.
> If needed, go up. If nobody answers CQ, go down. If JT65 is heard, avoid
> it.
>
> Best point for DX-peditions is just above: they transmit on 3 kHz, thus
> anyone can see
> they are QRV and move to work fox. But hunds are outside normal FT8 QRG.
>
>
> 6. Maybe SPLIT is needed?
>
> I recall 2017 JT65 madness on 6m: EU/JA and EU/W agreed on even/odd
> periods.
> Waiting for FT8 this year.
>
> Also, it is much easier to work JA on 160m compared to 80m (or 40m) from
> Europe.
> reason: JA is transmitting 1908, we are on 1840. So, if I want that HA6
> station from rare UL square, I do simplex,
> if I want JA DX, I listen 908.
>
> Maybe a recommendation to use similar approach can return "weak signal" to
> FT8 DXing?
> EU/NA/AS-OC/rare DX subbands.
>
>
>
> Best 73, gd FT8 DX
> Iztok, S52D
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Pravni pogoji / Legal disclaimer
> Telekom Slovenije, d.d., Ljubljana 
>
>
> 
> --
> 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

[wsjt-devel] FT8 TX2 response Bug?

[Rich - K1HTV]

TX2 bug response in v1.9.0-rc3


At times, multiple callers answer my CQs. The decoded red lines from both 
callers appear as expected, in both the 'Band Activity' and 'RxFrequency' 
columns. After working the first station, if the next station I want to work is 
sending me a Tx2 message (Calls & Report), when I double click on his call in 
the 'RXFrequency' column, instead of my sending a TX3 message, my automatic 
response is an incorrect TX2 message.


If on the other hand I double click on the same station callsign in the 'Band 
Activity' column, I start sending the correct TX3 message.


A Bug?


73,
Rich - K1HTV--
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?

[Iztok Saje]

Hello!

Summary: Do not over regulate HAM bands!
Please emphasize in doccumantation:
"FT8 frequencies are recommendation, not Law".

Few different ideas for "FT8 frequencies" discussion.

1. Fresh from CQ WPX SSB.

On 80 m, somebody kept telling people calling CQ below 3700:
"This frequency is not for contest, please QSY, read IARU bla bla ...".

On the other hand: on 160 m, there was no FT8 for 48 hours.
And some CW was lost in first few kHz (QRMed by non-HAM QRM anyhow).
Whole first 100 kHz was SSB.
5 minutes after contest, FT8 activity is restarted.

It was similar with RTTY contests: FT8 traffic declined and moved to 7 MHz (where FT8 is 
in the "SSB" part) and WARC.

The other day somenone on 40m kept sending beacon (FT8 beacon) saying "This is JT65, 
not FT8"
AT the same time, no JT65 signals was heard, and FT8 was crowded.

2. Shared space
is nice approach https://en.wikipedia.org/wiki/Shared_space ,
reinvented by https://en.wikipedia.org/wiki/Hans_Monderman .
(I recall traffic in Kairo: I would not dare to drive, but everything run 
smoothly).
Concept is simple: by over regulation (Traffic signs, lights, zebras ...) 
drivers rely on signs,
ignore other drivers and several crashes are due to "It is my right to be 
there").
By removing signs, drivers start to observe and respect others. Less accidents, 
higher throughput.


3. HAM bands are shared space from day 1

I see HAM bands as shared space. Yes, I did CW QSOs on "SSB" part. Yes, I used 
FT8 outside preferred FT8 2 kHz.
Yes, I was using RTTY on JT65 subband.
Yes, I do QSY if there is major contest going on.


Any FT8/JT65/JT9/PSK/name_it allocation is just recommendation.
It is frequency where it is most likely to find some activity.
No more, no less. And it should be like this.
All digital modes equal.

4. HAM spirit
With respect to others, it is easy to find place for everyone.
More FT8: FT8 expands. More RTTY: FT8 shrinks.
Less PSK: sorry, it is not fair to keep 2 kHz empty while FT8 is suffering.

I recall when first 10 kHz on 7 MHz was DX reserved. There is good reason why 
it is no more.

Of course, we have different people on the bands: whatever I do, somebody does 
not like.
But those people will always find something to dislike and some mission on the 
bands.

5. current practice
Yes, we tend to go up. My RX bandwidth is 3.4 kHz. And TX as well.
If needed, go up. If nobody answers CQ, go down. If JT65 is heard, avoid it.

Best point for DX-peditions is just above: they transmit on 3 kHz, thus anyone 
can see
they are QRV and move to work fox. But hunds are outside normal FT8 QRG.


6. Maybe SPLIT is needed?

I recall 2017 JT65 madness on 6m: EU/JA and EU/W agreed on even/odd periods.
Waiting for FT8 this year.

Also, it is much easier to work JA on 160m compared to 80m (or 40m) from Europe.
reason: JA is transmitting 1908, we are on 1840. So, if I want that HA6 station 
from rare UL square, I do simplex,
if I want JA DX, I listen 908.

Maybe a recommendation to use similar approach can return "weak signal" to FT8 
DXing?
EU/NA/AS-OC/rare DX subbands.



Best 73, gd FT8 DX
Iztok, S52D


































Pravni pogoji / Legal disclaimer
Telekom Slovenije, d.d., Ljubljana 

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

Hi Alex,

patch works fine for me:

bill@BILLS_LENOVO ~/src/wsjt ((a4e77bb...))

$ patch --dry-run -p1 <~/Dropbox/Public/highlight.diff
patching file `CMakeLists.txt'
patching file `MessageClient.cpp'
patching file `MessageClient.hpp'
patching file `MessageServer.cpp'
patching file `MessageServer.hpp'
patching file `NetworkMessage.hpp'
patching file `UDPExamples/ClientWidget.cpp'
patching file `UDPExamples/ClientWidget.hpp'
patching file `UDPExamples/MessageAggregatorMainWindow.cpp'
patching file `UDPExamples/MessageAggregatorMainWindow.hpp'
patching file `displaytext.cpp'
patching file `displaytext.h'
patching file `mainwindow.cpp'

bill@BILLS_LENOVO ~/src/wsjt ((a4e77bb...))
$ which patch
/bin/patch

Using the patch utility found in a Windows git-bash installation but any 
correctly installed GNU patch should work.


73
Bill
G4WJS.

On 26/03/2018 02:26, Alex, VE3NEA wrote:

Hi Bill,

The patch utility crashes when trying to apply this patch. Do I need 
to specify some extra command line switches? Maybe you could create a 
branch with your changes that I would check out instead?


73 Alex VE3NEA



On 2018-03-25 18:52, Bill Somerville wrote:

Hi Alex,

I have added a few enhancements to your proposed patch:

https://www.dropbox.com/s/7slm4oypbc5g8ks/highlight.diff?dl=0

this extends the UDP message to include the foreground colour as well 
as the background colour. The colours are passed as QColor format 
fields which are a little more complicated but are already supported 
by the Qt QDataStream formats. The main reason for the field format 
is that QColor can specify many more colours and also an  invalid 
colour value (spec = 0). The invalid value is used to reset the 
background and or foreground colour to defaults. The internal 
implementation in WSJT-X keeps a dictionary of highlight commands 
send and applies the colours to all existing decodes and future 
decodes, this should explain the need for a resetting mechanism.


As an example I have enhanced the WSJT-X MessageServer class and the 
reference message_aggregator application (the C++ Qt one) provided 
with WSJT-X to exercise the new UDP message, it does so by displaying 
a list of "calls of interest" which it relays to all connected WSJT-X 
clients. Callsigns may be added to, edited, and deleted (right-click 
the list for a context menu).


Give it a try and see what you think.

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