Date   

Re: Added complexity when transmitting while multiple WSJT-X instances are running on a station with a shared TX resource with 2.3.0-rc2

N1BUG <paul@...>
 

Hi Clint, Bill, and all.

This was a really big and disappointing change for me as well. If there were no workaround it forced a complete rethinking of operating practices, but no matter how I thought about it I could not get around the concern that some QSOs could be missed if I couldn't have several instances running and instantly start transmitting with any of them. If you miss the first chance to call with 1800 second T/R periods that next opportunity is a long way off. The station may have quit or have other callers by then, or perhaps the propagation window is just too short.

Normally I am not one to solve a problem by adding additional software, especially non-free software. But I considered this mission critical. On a suggestion from VE7VV I installed VSPE from Eterlogic and that has solved the problem. I can now continue operating as I had been, with multiple instances open, freely switching between them for transmitting without worry about conflicts. I've configured a splitter in VSPE with my physical port, COM3 as input and output configured as virtual port COM5.

73,
Paul N1BUG


Re: RC2 MSK144 Bug

Brad Fuller
 

Bill,
I have attached 2 Wav files below.
155615 is the sequence before starting transmit.
155645 is the sequence after transmitting.
Brad
WQ5S

On Sun, Nov 22, 2020 at 9:01 AM Bill Somerville <g4wjs@...> wrote:
On 22/11/2020 14:54, Brad Fuller wrote:
> While trying to operate MSK144 I noticed that after the first TX
> sequence on the return to RX I get a pulsing 2 tone birdy on RX. The
> birdy goes away as soon as I close WSJTX and after restarting WSJTX
> and or reboot of the computer the birdy returns after the first TX
> sequence.
> Reverting back to Version 2.2.2 and the problem is not there. The
> previous RC1 also did not have this issue.
> This is on WSJT-X v2.3.0-rc2 4c05f8

Hi Brad,

can you provide a .WAV file recorded by WSJT-X that demonstrates this
please?

73
Bill
G4WJS.






--
Brad Fuller
WQ5S


WSJT-X Tx display size too small

Amos Sobel 4X4MF
 

WSJT-X users

Some times I find myself of traying to transmit on 2 out of my 4 WSJT-X instances., which does produce a mass .
One reason to this kind of mistake is the small size of the red and yellow Tx display as in the snip below.
Joe and Bill, please consider  increasing the size of the Tx display to make it more visible, say by painting the date/time display in red during Tx time.

Amos 4X4MF


Re: WSJT-X with IC-7000, Ubuntu, mhuxd, and a Digi Keyer II

Joe Subich, W4TV
 

When I am running Ubuntu I am selecting "ICOM IC-7000" as the "Rig" and the "Transmit Audio Source" on the "Radio" tab is grayed and selected to "Front/Mic". The Digii Keyer II is also telling me the Mic is selected as the audio source. I know this because the "Line" light on the front of the device is flashing. When "Rear/Data" is selected (running on Windows and using HRD) the light is solid red, indicating the audio source is the rear data port.
I don't know anything about LINUX however ...

1) The IC-7000 mic and ACC jacks are effectively in parallel. The
IC-7000 does not have a USB_D mode and does not provide for
selecting audio source (MIC or ACC) based on mode.
2) Digieyer II connects to the ACC jack - there is no provision for
setting "mic" audio.
3) the flashing LINE LED on DK II indicates you have selected
"Headset microphone (microHAM CODEC)" *FOR INPUT* (receive)
in WSJTX (however that is indicated in LINUX). You will need
to fix your File -> Settings -> Audio -> input selection in
WSJTX.

73,

... Joe, W4TV


On 2020-11-21 4:59 PM, sd_wireless via groups.io wrote:
I am trying to get WSJT-X working with an IC-7000, Ubuntu, mhuxd, and a Digi Keyer II. At this point, rig control seems to be working fine. Where I am having problems is with audio.
One oddity I've noted appears to be driven by the choice of the "Rig" on the "Radio" tab. When I am running WSJT-X on Windows I select "Ham Radio Deluxe" as the "Rig" and the "Transmit Audio Source" on the "Radio" tab is available to me.
When I am running Ubuntu I am selecting "ICOM IC-7000" as the "Rig" and the "Transmit Audio Source" on the "Radio" tab is grayed and selected to "Front/Mic". The Digii Keyer II is also telling me the Mic is selected as the audio source. I know this because the "Line" light on the front of the device is flashing. When "Rear/Data" is selected (running on Windows and using HRD) the light is solid red, indicating the audio source is the rear data port.
Is there any way to get WSJT-X to allow me to select the "Rear/Data" port when the "Rig" is set to "ICOM IC-7000"?
Note, the behavior of WSJT-X and the Digi Keyer do not change regardless of the "Mode" setting on the IC-7000. They both function the same regardless of whether USB or RTTY are selected on the radio.


Re: RC2 MSK144 Bug

Bill Somerville
 

On 22/11/2020 14:54, Brad Fuller wrote:
While trying to operate MSK144 I noticed that after the first TX sequence on the return to RX I get a pulsing 2 tone birdy on RX. The birdy goes away as soon as I close WSJTX and after restarting WSJTX and or reboot of the computer the birdy returns after the first TX sequence.
Reverting back to Version 2.2.2 and the problem is not there. The previous RC1 also did not have this issue.
This is on WSJT-X v2.3.0-rc2 4c05f8
Hi Brad,

can you provide a .WAV file recorded by WSJT-X that demonstrates this please?

73
Bill
G4WJS.


moderated Re: Auto-sequence definately fouled up!

JP Tucson, AZ
 

Hi Roger,

no, I don't have an rfi issue, the mouse & kb have ferrites & the pc is grounded to the single point station ground.  I have also swept my for stray rf with a field strength meter - nothing at all, anywhere in the shack!

I am not sure how the mouse pad has or could have any effect, as it's 100% non conductive - it's silicone/gel.



73 - John - N7GHZ




On Sun, Nov 22, 2020, 5:29 AM <groups@...> wrote:
On 22/11/2020 12:14, Bill Somerville wrote:
> On 22/11/2020 06:03, JP Tucson, AZ wrote:
>> Again, the thing has lost its mind!
>>
>> It is all over the place!!!
>>
>> Sometimes, after a 73, it sends you back to an "R-xx" report,
>> sometimes as the attached shows, it sends you back to the CQ call
>> (TX1) that you just completed.
>>
>> And sometimes it now just stops, it didn't do anything...!  It had tx
>> enabled and should have went to CQ - TX6, instead it just hung up
>> (stayed in RX/monitor mode & kept rx) even though the red - enable tx
>> was on. I had to hit Halt TX (3 times!), then re-enable TX before it
>> would do anything.
>>
>> All cpu indications are clear, nowhere near limits on cpu or graphics,
>> can start other programs (like gmail) & all works fine w/wsjtx
>> running, until it loses its mind again a few cycles later.  I did a
>> full shut down, 5 min., then restart, with nothing else running, it
>> went crazy again after 3 cycles, that's when I snipped the image below.
>>
>> Completed N6RCS, then it went back to calling N5CRS again on CQ, even
>> though I selected K7KE
>> Had to manually reselect K7KE again, went thru & completed that QSO &
>> it did it again, not shown in this snip.
>>
>> It started off ok, but now its getting worse.
>
> John,
>
> referring to "the thing" and "it" in your description of an issue is
> most unhelpful, nor do I have the faintest idea what actions you took in
> the exchange you describe. For example, did you log the QSO, if so at
> what point? Did you double-click the 73 response from your QSO partner
> or did the retransmission of your Tx1 message happen spontaneously? Do
> you have "Settings->Reporting->Prompt me to log QSO" checked? Do you
> have "Settings->Reporting->Clear DX call and grid after logging"
> checked? Do you have "Settings->General->Disable Tx after sending 73"
> checked?
>
> 73
> Bill
> G4WJS.
>
>
John

I have one further suggestion.  Have you checked that your mouse or pad
is not subject to RFI?  I have a USB mouse that produces left clicks on
80m and top band.

73
Roger
GW4HZA




moderated Re: Auto-sequence definately fouled up!

Bill Somerville
 

Hi John,

OK, I suspect the issue relates to your not having "Settings->Reporting->Clear DX call and grid after logging", that action "clears down" the QSO. Although it should not be responding again in the way that it did, and I will resolve that, I recommend you either set that option or at least hit ESC when you are done with a QSO so that WSJTY-X knows you are done with it. Note logging does not necessary say you are done with the QSO, many of us log upon receipt of an R+report but continue with the QSO until we are sure a QSO partner has received their RRR or RR73 acknowledgement.

73
Bill
G4WJS.

On 22/11/2020 14:45, JP Tucson, AZ wrote:
O...k...

I thought it was pretty clear, but I'll try to clarify... (smart ass remark warning - humor not being offensive - you're in England, you sure English is your native language? 🤨)

I'll answer below in red...

Thanks Bill

73 - John - N7GHZ

On Sun, Nov 22, 2020, 5:14 AM Bill Somerville <g4wjs@...> wrote:
On 22/11/2020 06:03, JP Tucson, AZ wrote:
> Again, the thing has lost its mind!
>
> It is all over the place!!!
>
> Sometimes, after a 73, it sends you back to an "R-xx" report,
> sometimes as the attached shows, it sends you back to the CQ call
> (TX1) that you just completed.
>
> And sometimes it now just stops, it didn't do anything...!  It had tx
> enabled and should have went to CQ - TX6, instead it just hung up
> (stayed in RX/monitor mode & kept rx) even though the red - enable tx
> was on. I had to hit Halt TX (3 times!), then re-enable TX before it
> would do anything.
>
> All cpu indications are clear, nowhere near limits on cpu or graphics,
> can start other programs (like gmail) & all works fine w/wsjtx
> running, until it loses its mind again a few cycles later.  I did a
> full shut down, 5 min., then restart, with nothing else running, it
> went crazy again after 3 cycles, that's when I snipped the image below.
>
> [[[Completed N6RCS, then it went back to calling N5CRS again on CQ, even
> though I selected K7KE
> Had to manually reselect K7KE again, went thru & completed that QSO]]] &
> it did it again, not shown in this snip.
>
> It started off ok, but now its getting worse.

John,

referring to "the thing" and "it" in your description of an issue is
most unhelpful,[meaning the auto sequencer, as I stated in the title   -"Auto-sequence(r)definately fouled up!"] nor do I have the faintest idea what actions you took in
the exchange you describe. [I actually did, see the triple brackets above ([[[)] For example, did you log the QSO [yes, as I indicated when I stated that I completed the QSO - meaning I logged it!], if so at
what point? [When it (wsjtx) went to TX4 (RRR) & popped up the log box & I did, and it's in the log]   Did you double-click the 73 response from your QSO partner
or did the retransmission of your Tx1 message happen spontaneously? [The latter, as I didn't touch anything until after I sent my final 73 & then selected my next tart station - K7KE - - - INSTEAD of calling K7KE as I directed, it went back to TX1 with "CQ K6RCS N7GHZ DM42"] Do
you have "Settings->Reporting->Prompt me to log QSO" checked? [YES] Do you
have "Settings->Reporting->Clear DX call and grid after logging"
checked? [No, never have] Do you have "Settings->General->Disable Tx after sending 73"
checked?[No]

So that you see the answer to Roger's Q.,  no, I don't have an rfi issue, the mouse & kb have ferrites % the pc is grounded to the single point station ground.  I have also swept my for stray rf with a field strength meter - nothing at all, anywhere in the shack!


73
Bill
G4WJS.



moderated Re: Auto-sequence definately fouled up!

JP Tucson, AZ
 

Hi again Bill,

Forgot to mention that when I just re-looked at the snip I sent you;

...that I noticed that on the RRR TX-R *ALSO*  had an "a3" attached to it as I do have 'Enable AP' turned on.  Don't know if that could throw a monkey wrench into the works...

By the way, just worked Reunion island!  Furthest point on Earth from me - on land - that I can go.  Woo-hoo!

73 - John - N7GHZ


On Sun, Nov 22, 2020, 5:14 AM Bill Somerville <g4wjs@...> wrote:
On 22/11/2020 06:03, JP Tucson, AZ wrote:
> Again, the thing has lost its mind!
>
> It is all over the place!!!
>
> Sometimes, after a 73, it sends you back to an "R-xx" report,
> sometimes as the attached shows, it sends you back to the CQ call
> (TX1) that you just completed.
>
> And sometimes it now just stops, it didn't do anything...!  It had tx
> enabled and should have went to CQ - TX6, instead it just hung up
> (stayed in RX/monitor mode & kept rx) even though the red - enable tx
> was on. I had to hit Halt TX (3 times!), then re-enable TX before it
> would do anything.
>
> All cpu indications are clear, nowhere near limits on cpu or graphics,
> can start other programs (like gmail) & all works fine w/wsjtx
> running, until it loses its mind again a few cycles later.  I did a
> full shut down, 5 min., then restart, with nothing else running, it
> went crazy again after 3 cycles, that's when I snipped the image below.
>
> Completed N6RCS, then it went back to calling N5CRS again on CQ, even
> though I selected K7KE
> Had to manually reselect K7KE again, went thru & completed that QSO &
> it did it again, not shown in this snip.
>
> It started off ok, but now its getting worse.

John,

referring to "the thing" and "it" in your description of an issue is
most unhelpful, nor do I have the faintest idea what actions you took in
the exchange you describe. For example, did you log the QSO, if so at
what point? Did you double-click the 73 response from your QSO partner
or did the retransmission of your Tx1 message happen spontaneously? Do
you have "Settings->Reporting->Prompt me to log QSO" checked? Do you
have "Settings->Reporting->Clear DX call and grid after logging"
checked? Do you have "Settings->General->Disable Tx after sending 73"
checked?

73
Bill
G4WJS.





RC2 MSK144 Bug

Brad Fuller
 

While trying to operate MSK144 I noticed that after the first TX sequence on the return to RX I get a pulsing 2 tone birdy on RX. The birdy goes away as soon as I close WSJTX and after restarting WSJTX and or reboot of the computer the birdy returns after the first TX sequence.
Reverting back to Version 2.2.2 and the problem is not there. The previous RC1 also did not have this issue.
This is on WSJT-X v2.3.0-rc2 4c05f8
image.png


image.png

Brad Fuller
WQ5S


moderated Re: Auto-sequence definately fouled up!

JP Tucson, AZ
 

O...k...

I thought it was pretty clear, but I'll try to clarify... (smart ass remark warning - humor not being offensive - you're in England, you sure English is your native language? 🤨)

I'll answer below in red...

Thanks Bill

73 - John - N7GHZ

On Sun, Nov 22, 2020, 5:14 AM Bill Somerville <g4wjs@...> wrote:
On 22/11/2020 06:03, JP Tucson, AZ wrote:
> Again, the thing has lost its mind!
>
> It is all over the place!!!
>
> Sometimes, after a 73, it sends you back to an "R-xx" report,
> sometimes as the attached shows, it sends you back to the CQ call
> (TX1) that you just completed.
>
> And sometimes it now just stops, it didn't do anything...!  It had tx
> enabled and should have went to CQ - TX6, instead it just hung up
> (stayed in RX/monitor mode & kept rx) even though the red - enable tx
> was on. I had to hit Halt TX (3 times!), then re-enable TX before it
> would do anything.
>
> All cpu indications are clear, nowhere near limits on cpu or graphics,
> can start other programs (like gmail) & all works fine w/wsjtx
> running, until it loses its mind again a few cycles later.  I did a
> full shut down, 5 min., then restart, with nothing else running, it
> went crazy again after 3 cycles, that's when I snipped the image below.
>
> [[[Completed N6RCS, then it went back to calling N5CRS again on CQ, even
> though I selected K7KE
> Had to manually reselect K7KE again, went thru & completed that QSO]]] &
> it did it again, not shown in this snip.
>
> It started off ok, but now its getting worse.

John,

referring to "the thing" and "it" in your description of an issue is
most unhelpful,[meaning the auto sequencer, as I stated in the title   -"Auto-sequence(r)definately fouled up!"] nor do I have the faintest idea what actions you took in
the exchange you describe. [I actually did, see the triple brackets above ([[[)] For example, did you log the QSO [yes, as I indicated when I stated that I completed the QSO - meaning I logged it!], if so at
what point? [When it (wsjtx) went to TX4 (RRR) & popped up the log box & I did, and it's in the log]   Did you double-click the 73 response from your QSO partner
or did the retransmission of your Tx1 message happen spontaneously? [The latter, as I didn't touch anything until after I sent my final 73 & then selected my next tart station - K7KE - - - INSTEAD of calling K7KE as I directed, it went back to TX1 with "CQ K6RCS N7GHZ DM42"] Do
you have "Settings->Reporting->Prompt me to log QSO" checked? [YES] Do you
have "Settings->Reporting->Clear DX call and grid after logging"
checked? [No, never have] Do you have "Settings->General->Disable Tx after sending 73"
checked?[No]

So that you see the answer to Roger's Q.,  no, I don't have an rfi issue, the mouse & kb have ferrites % the pc is grounded to the single point station ground.  I have also swept my for stray rf with a field strength meter - nothing at all, anywhere in the shack!


73
Bill
G4WJS.





Re: Communicating with WSJT-X over UDP #udp

Bill Somerville
 

On 22/11/2020 14:08, Philip Rose via groups.io wrote:

Thanks, Bill.

 

I wasn’t sure I understood that there could be more than one server. You say ‘interoperating’, surely a server would only respond to UDPs addressed to it. Or can an application be server and client? Or several servers having the same address? What other applications are likely to be servers? Do you expect people to have multiple loggers? What other sort of applications would be servers?

 

73 Phil GM3ZZA.

Hi Phil,

one of the reasons why WSJT-X uses UDP for interoperation with other applications is because that allows a many-to-many topology without having to use different service ports for each server. This is enabled by using multicast IP, a server can bind a service port using SO_REUSEADDR and join a multicast group to express an interest in datagrams sent to that group. The networking infrastructure will deliver such datagrams, by copying them if necessary (multicast is the only networking protocol where packets can be copied) so that every member of a multicast group can receive their own copy of each datagram.

There are already several applications that can run in parallel as servers interoperating with WSJT-X instances. JTAlert, Gridtracker, and WSJT-X Monitor for example. They often do have some overlap in functionality, but that's fine so long as only one of them is responsible for logging QSOs in any main station log.

73
Bill
G4WJS.


Re: Communicating with WSJT-X over UDP #udp

Bill Somerville
 

Hi Phil,

Tom's library doesn't handle schema negotiation either. It appears to force the "mesh" schema number to 2, which is acceptable but not necessarily very friendly. Also it does not decode the QDate field NULL value, which is the difference between schema numbers 2 and 3, so it doesn't grok the different schema either.

73
Bill
G4WJS.

On 22/11/2020 14:10, Philip Rose via groups.io wrote:

Thanks Tom,

 

I’ve already implemented a UDP server for WSJT-X in my hb logger, but it doesn’t handle schema negotiation correctly (according to Bill’s reply). I might look at replacing it with your lib.

 

73 Phil GM3ZZA

 

Sent from Mail for Windows 10

 

From: Tom M0LTE
Sent: 22 November 2020 12:08
To: main@wsjtx.groups.io
Subject: Re: [WSJTX] Communicating with WSJT-X over UDP #udp

 

Hi Lado

 

Rather than starting from scratch, I encourage you to use, and indeed extend via submitting PRs, this:

 

Thanks

Tom

 

On Sun, 22 Nov 2020 at 12:04, Bill Somerville <g4wjs@...> wrote:

On 22/11/2020 07:31, s53c.lado@... wrote:
> I'm working on (yet another) ham logging program written in c#. I do
> not have big plans for it: It is just a project I am using as a means
> to learn something new and to help me pass my retirement days. Right
> now I am trying to add communication between WSJT-X and this logging
> program. So far I am able to decode most of the messages coming from
> WSJT-X , Where I am stuck is that I don't understand the schema
> negotiation between WSJT-X  and UDP server. Datagram from UDP server
> to WSJT-X seems to be defined in NetworkMessage part of
> NetworkMessage.hpp. But as I know practically nothing of C++, I am not
> able to read and interpret what's written there. So I kindly ask if
> there is someone to show how the message from UDP server to WSJT-X 
> should be constructed in a way like messages from WSJT-X to UDP
> servers are described.
>
> Lado, S53C

Hi Lado,

firstly you need to understand that there may be many WSJT-X instances
*and* interoperating server applications like your logging program
working together in what I will refer to as a "mesh". Each may be
written and updated at different times and can only be expected to
understand the data type schema at the time they were last updated. To
allow the "mesh" of applications to interoperate there must be a lowest
common denominator schema that they all understand. The schema
negotiation is how this is occurs. Each new application joining the
"mesh" shall wait for a Heartbeat message and examine the current schema
being used, it shall then reply with another Heartbeat message that
contains the highest schema number it can work with. The WSJT-X client
receiving that Heartbeat message will adjust it's outgoing schema by
lowering it to match if necessary. That in turn will be received by all
server applications in the "mesh" and they in turn will adjust if
necessary. The result, eventually, will be all applications will settle
on the adjusted schema number. You application shall always monitor the
schema number of incoming traffic and be prepared to move to a lower
schema number. It is forbidden to send a message with a higher schema
number than any previously received schema number in a given operating
session.

Note that the schema number is not the schema of the data messages and
fields within them, it is the schema of the underlying data types. This
means the schema only changes very rarely when a data type encoding has
to change. Note also that neither new fields appended to existing
messages, or new message types, even if new data types included,do not
require a new schema number. A new schema number is *only* necessary if
an data type of a field used in an already published message type has a
change in the encoding of that type.

To make this schema scheme work we guarantee that no message field in
existing messages will be changed, only new fields appended to existing
message types, or new message types will be added. To comply with this
your application must be prepared to receive datagrams that are longer
than the expected sum of fields, or indeed new unknown message types.
Both of these cases should be silently ignored as they represent updates
to the messages for a newer version than the one your application was
coded to support. Of course you can update you application to recognize
those new fields and message types in your own time.

You application shall be prepared to receive messages with any schema up
to and equal to the maximum schema it understands. There are currently
three possible schema numbers (1, 2, and 3), but as noted in
Network/NetworkMessage.hpp schema number 1 is broken and obsolete so
will never be used, so currently you must support schema numbers 2 and
3. The difference lies in the encoding of the QDateTime type, in schema
2 QTime components with a value of 0 represent NULL whereas in schema 3
-1 represents NULL. There are also changes in the QDate component but
only in the timespec field and we guarantee to only use the UTC timespec
where there is no difference be tween schema numbers 2 and 3.

The current list of message types and fields is documented in the WSJT-X
project source repository in this file:

https://sourceforge.net/p/wsjt/wsjtx/ci/master/tree/Network/NetworkMessage.hpp

in the commentary at the top. This file may be updated at any WSJT-X
public release so authors of interoperating applications should monitor
the history of this file for changes at those times if they wish to
track any recent changes. No C++ knowledge is required as the commentary
has all the information you need, or hyperlinks to further reading for it.

73
Bill
G4WJS.



 


--
73 Phil GM3ZZA



Re: Communicating with WSJT-X over UDP #udp

 

Thanks Tom,

 

I’ve already implemented a UDP server for WSJT-X in my hb logger, but it doesn’t handle schema negotiation correctly (according to Bill’s reply). I might look at replacing it with your lib.

 

73 Phil GM3ZZA

 

Sent from Mail for Windows 10

 

From: Tom M0LTE
Sent: 22 November 2020 12:08
To: main@wsjtx.groups.io
Subject: Re: [WSJTX] Communicating with WSJT-X over UDP #udp

 

Hi Lado

 

Rather than starting from scratch, I encourage you to use, and indeed extend via submitting PRs, this:

 

Thanks

Tom

 

On Sun, 22 Nov 2020 at 12:04, Bill Somerville <g4wjs@...> wrote:

On 22/11/2020 07:31, s53c.lado@... wrote:
> I'm working on (yet another) ham logging program written in c#. I do
> not have big plans for it: It is just a project I am using as a means
> to learn something new and to help me pass my retirement days. Right
> now I am trying to add communication between WSJT-X and this logging
> program. So far I am able to decode most of the messages coming from
> WSJT-X , Where I am stuck is that I don't understand the schema
> negotiation between WSJT-X  and UDP server. Datagram from UDP server
> to WSJT-X seems to be defined in NetworkMessage part of
> NetworkMessage.hpp. But as I know practically nothing of C++, I am not
> able to read and interpret what's written there. So I kindly ask if
> there is someone to show how the message from UDP server to WSJT-X 
> should be constructed in a way like messages from WSJT-X to UDP
> servers are described.
>
> Lado, S53C

Hi Lado,

firstly you need to understand that there may be many WSJT-X instances
*and* interoperating server applications like your logging program
working together in what I will refer to as a "mesh". Each may be
written and updated at different times and can only be expected to
understand the data type schema at the time they were last updated. To
allow the "mesh" of applications to interoperate there must be a lowest
common denominator schema that they all understand. The schema
negotiation is how this is occurs. Each new application joining the
"mesh" shall wait for a Heartbeat message and examine the current schema
being used, it shall then reply with another Heartbeat message that
contains the highest schema number it can work with. The WSJT-X client
receiving that Heartbeat message will adjust it's outgoing schema by
lowering it to match if necessary. That in turn will be received by all
server applications in the "mesh" and they in turn will adjust if
necessary. The result, eventually, will be all applications will settle
on the adjusted schema number. You application shall always monitor the
schema number of incoming traffic and be prepared to move to a lower
schema number. It is forbidden to send a message with a higher schema
number than any previously received schema number in a given operating
session.

Note that the schema number is not the schema of the data messages and
fields within them, it is the schema of the underlying data types. This
means the schema only changes very rarely when a data type encoding has
to change. Note also that neither new fields appended to existing
messages, or new message types, even if new data types included,do not
require a new schema number. A new schema number is *only* necessary if
an data type of a field used in an already published message type has a
change in the encoding of that type.

To make this schema scheme work we guarantee that no message field in
existing messages will be changed, only new fields appended to existing
message types, or new message types will be added. To comply with this
your application must be prepared to receive datagrams that are longer
than the expected sum of fields, or indeed new unknown message types.
Both of these cases should be silently ignored as they represent updates
to the messages for a newer version than the one your application was
coded to support. Of course you can update you application to recognize
those new fields and message types in your own time.

You application shall be prepared to receive messages with any schema up
to and equal to the maximum schema it understands. There are currently
three possible schema numbers (1, 2, and 3), but as noted in
Network/NetworkMessage.hpp schema number 1 is broken and obsolete so
will never be used, so currently you must support schema numbers 2 and
3. The difference lies in the encoding of the QDateTime type, in schema
2 QTime components with a value of 0 represent NULL whereas in schema 3
-1 represents NULL. There are also changes in the QDate component but
only in the timespec field and we guarantee to only use the UTC timespec
where there is no difference be tween schema numbers 2 and 3.

The current list of message types and fields is documented in the WSJT-X
project source repository in this file:

https://sourceforge.net/p/wsjt/wsjtx/ci/master/tree/Network/NetworkMessage.hpp

in the commentary at the top. This file may be updated at any WSJT-X
public release so authors of interoperating applications should monitor
the history of this file for changes at those times if they wish to
track any recent changes. No C++ knowledge is required as the commentary
has all the information you need, or hyperlinks to further reading for it.

73
Bill
G4WJS.



 


--
73 Phil GM3ZZA


Re: Communicating with WSJT-X over UDP #udp

 

Thanks, Bill.

 

I wasn’t sure I understood that there could be more than one server. You say ‘interoperating’, surely a server would only respond to UDPs addressed to it. Or can an application be server and client? Or several servers having the same address? What other applications are likely to be servers? Do you expect people to have multiple loggers? What other sort of applications would be servers?

 

73 Phil GM3ZZA.

 

Sent from Mail for Windows 10

 

From: Bill Somerville
Sent: 22 November 2020 12:04
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Communicating with WSJT-X over UDP #udp

 

O

 


--
73 Phil GM3ZZA


moderated Re: Auto-sequence definately fouled up!

groups@...
 

On 22/11/2020 12:14, Bill Somerville wrote:
On 22/11/2020 06:03, JP Tucson, AZ wrote:
Again, the thing has lost its mind!

It is all over the place!!!

Sometimes, after a 73, it sends you back to an "R-xx" report, sometimes as the attached shows, it sends you back to the CQ call (TX1) that you just completed.

And sometimes it now just stops, it didn't do anything...!  It had tx enabled and should have went to CQ - TX6, instead it just hung up (stayed in RX/monitor mode & kept rx) even though the red - enable tx was on. I had to hit Halt TX (3 times!), then re-enable TX before it would do anything.

All cpu indications are clear, nowhere near limits on cpu or graphics, can start other programs (like gmail) & all works fine w/wsjtx running, until it loses its mind again a few cycles later.  I did a full shut down, 5 min., then restart, with nothing else running, it went crazy again after 3 cycles, that's when I snipped the image below.

Completed N6RCS, then it went back to calling N5CRS again on CQ, even though I selected K7KE
Had to manually reselect K7KE again, went thru & completed that QSO & it did it again, not shown in this snip.

It started off ok, but now its getting worse.
John,
referring to "the thing" and "it" in your description of an issue is most unhelpful, nor do I have the faintest idea what actions you took in the exchange you describe. For example, did you log the QSO, if so at what point? Did you double-click the 73 response from your QSO partner or did the retransmission of your Tx1 message happen spontaneously? Do you have "Settings->Reporting->Prompt me to log QSO" checked? Do you have "Settings->Reporting->Clear DX call and grid after logging" checked? Do you have "Settings->General->Disable Tx after sending 73" checked?
73
Bill
G4WJS.
John

I have one further suggestion. Have you checked that your mouse or pad is not subject to RFI? I have a USB mouse that produces left clicks on 80m and top band.

73
Roger
GW4HZA


moderated Re: Auto-sequence definately fouled up!

Bill Somerville
 

On 22/11/2020 06:03, JP Tucson, AZ wrote:
Again, the thing has lost its mind!

It is all over the place!!!

Sometimes, after a 73, it sends you back to an "R-xx" report, sometimes as the attached shows, it sends you back to the CQ call (TX1) that you just completed.

And sometimes it now just stops, it didn't do anything...!  It had tx enabled and should have went to CQ - TX6, instead it just hung up (stayed in RX/monitor mode & kept rx) even though the red - enable tx was on. I had to hit Halt TX (3 times!), then re-enable TX before it would do anything.

All cpu indications are clear, nowhere near limits on cpu or graphics, can start other programs (like gmail) & all works fine w/wsjtx running, until it loses its mind again a few cycles later.  I did a full shut down, 5 min., then restart, with nothing else running, it went crazy again after 3 cycles, that's when I snipped the image below.

Completed N6RCS, then it went back to calling N5CRS again on CQ, even though I selected K7KE
Had to manually reselect K7KE again, went thru & completed that QSO & it did it again, not shown in this snip.

It started off ok, but now its getting worse.
John,

referring to "the thing" and "it" in your description of an issue is most unhelpful, nor do I have the faintest idea what actions you took in the exchange you describe. For example, did you log the QSO, if so at what point? Did you double-click the 73 response from your QSO partner or did the retransmission of your Tx1 message happen spontaneously? Do you have "Settings->Reporting->Prompt me to log QSO" checked? Do you have "Settings->Reporting->Clear DX call and grid after logging" checked? Do you have "Settings->General->Disable Tx after sending 73" checked?

73
Bill
G4WJS.


Re: Communicating with WSJT-X over UDP #udp

Tom M0LTE
 

Hi Lado

Rather than starting from scratch, I encourage you to use, and indeed extend via submitting PRs, this:

Thanks
Tom

On Sun, 22 Nov 2020 at 12:04, Bill Somerville <g4wjs@...> wrote:
On 22/11/2020 07:31, s53c.lado@... wrote:
> I'm working on (yet another) ham logging program written in c#. I do
> not have big plans for it: It is just a project I am using as a means
> to learn something new and to help me pass my retirement days. Right
> now I am trying to add communication between WSJT-X and this logging
> program. So far I am able to decode most of the messages coming from
> WSJT-X , Where I am stuck is that I don't understand the schema
> negotiation between WSJT-X  and UDP server. Datagram from UDP server
> to WSJT-X seems to be defined in NetworkMessage part of
> NetworkMessage.hpp. But as I know practically nothing of C++, I am not
> able to read and interpret what's written there. So I kindly ask if
> there is someone to show how the message from UDP server to WSJT-X 
> should be constructed in a way like messages from WSJT-X to UDP
> servers are described.
>
> Lado, S53C

Hi Lado,

firstly you need to understand that there may be many WSJT-X instances
*and* interoperating server applications like your logging program
working together in what I will refer to as a "mesh". Each may be
written and updated at different times and can only be expected to
understand the data type schema at the time they were last updated. To
allow the "mesh" of applications to interoperate there must be a lowest
common denominator schema that they all understand. The schema
negotiation is how this is occurs. Each new application joining the
"mesh" shall wait for a Heartbeat message and examine the current schema
being used, it shall then reply with another Heartbeat message that
contains the highest schema number it can work with. The WSJT-X client
receiving that Heartbeat message will adjust it's outgoing schema by
lowering it to match if necessary. That in turn will be received by all
server applications in the "mesh" and they in turn will adjust if
necessary. The result, eventually, will be all applications will settle
on the adjusted schema number. You application shall always monitor the
schema number of incoming traffic and be prepared to move to a lower
schema number. It is forbidden to send a message with a higher schema
number than any previously received schema number in a given operating
session.

Note that the schema number is not the schema of the data messages and
fields within them, it is the schema of the underlying data types. This
means the schema only changes very rarely when a data type encoding has
to change. Note also that neither new fields appended to existing
messages, or new message types, even if new data types included,do not
require a new schema number. A new schema number is *only* necessary if
an data type of a field used in an already published message type has a
change in the encoding of that type.

To make this schema scheme work we guarantee that no message field in
existing messages will be changed, only new fields appended to existing
message types, or new message types will be added. To comply with this
your application must be prepared to receive datagrams that are longer
than the expected sum of fields, or indeed new unknown message types.
Both of these cases should be silently ignored as they represent updates
to the messages for a newer version than the one your application was
coded to support. Of course you can update you application to recognize
those new fields and message types in your own time.

You application shall be prepared to receive messages with any schema up
to and equal to the maximum schema it understands. There are currently
three possible schema numbers (1, 2, and 3), but as noted in
Network/NetworkMessage.hpp schema number 1 is broken and obsolete so
will never be used, so currently you must support schema numbers 2 and
3. The difference lies in the encoding of the QDateTime type, in schema
2 QTime components with a value of 0 represent NULL whereas in schema 3
-1 represents NULL. There are also changes in the QDate component but
only in the timespec field and we guarantee to only use the UTC timespec
where there is no difference be tween schema numbers 2 and 3.

The current list of message types and fields is documented in the WSJT-X
project source repository in this file:

https://sourceforge.net/p/wsjt/wsjtx/ci/master/tree/Network/NetworkMessage.hpp

in the commentary at the top. This file may be updated at any WSJT-X
public release so authors of interoperating applications should monitor
the history of this file for changes at those times if they wish to
track any recent changes. No C++ knowledge is required as the commentary
has all the information you need, or hyperlinks to further reading for it.

73
Bill
G4WJS.





Re: Communicating with WSJT-X over UDP #udp

Bill Somerville
 

On 22/11/2020 07:31, s53c.lado@gmail.com wrote:
I'm working on (yet another) ham logging program written in c#. I do not have big plans for it: It is just a project I am using as a means to learn something new and to help me pass my retirement days. Right now I am trying to add communication between WSJT-X and this logging program. So far I am able to decode most of the messages coming from WSJT-X , Where I am stuck is that I don't understand the schema negotiation between WSJT-X  and UDP server. Datagram from UDP server to WSJT-X seems to be defined in NetworkMessage part of NetworkMessage.hpp. But as I know practically nothing of C++, I am not able to read and interpret what's written there. So I kindly ask if there is someone to show how the message from UDP server to WSJT-X  should be constructed in a way like messages from WSJT-X to UDP servers are described.

Lado, S53C
Hi Lado,

firstly you need to understand that there may be many WSJT-X instances *and* interoperating server applications like your logging program working together in what I will refer to as a "mesh". Each may be written and updated at different times and can only be expected to understand the data type schema at the time they were last updated. To allow the "mesh" of applications to interoperate there must be a lowest common denominator schema that they all understand. The schema negotiation is how this is occurs. Each new application joining the "mesh" shall wait for a Heartbeat message and examine the current schema being used, it shall then reply with another Heartbeat message that contains the highest schema number it can work with. The WSJT-X client receiving that Heartbeat message will adjust it's outgoing schema by lowering it to match if necessary. That in turn will be received by all server applications in the "mesh" and they in turn will adjust if necessary. The result, eventually, will be all applications will settle on the adjusted schema number. You application shall always monitor the schema number of incoming traffic and be prepared to move to a lower schema number. It is forbidden to send a message with a higher schema number than any previously received schema number in a given operating session.

Note that the schema number is not the schema of the data messages and fields within them, it is the schema of the underlying data types. This means the schema only changes very rarely when a data type encoding has to change. Note also that neither new fields appended to existing messages, or new message types, even if new data types included,do not require a new schema number. A new schema number is *only* necessary if an data type of a field used in an already published message type has a change in the encoding of that type.

To make this schema scheme work we guarantee that no message field in existing messages will be changed, only new fields appended to existing message types, or new message types will be added. To comply with this your application must be prepared to receive datagrams that are longer than the expected sum of fields, or indeed new unknown message types. Both of these cases should be silently ignored as they represent updates to the messages for a newer version than the one your application was coded to support. Of course you can update you application to recognize those new fields and message types in your own time.

You application shall be prepared to receive messages with any schema up to and equal to the maximum schema it understands. There are currently three possible schema numbers (1, 2, and 3), but as noted in Network/NetworkMessage.hpp schema number 1 is broken and obsolete so will never be used, so currently you must support schema numbers 2 and 3. The difference lies in the encoding of the QDateTime type, in schema 2 QTime components with a value of 0 represent NULL whereas in schema 3 -1 represents NULL. There are also changes in the QDate component but only in the timespec field and we guarantee to only use the UTC timespec where there is no difference be tween schema numbers 2 and 3.

The current list of message types and fields is documented in the WSJT-X project source repository in this file:

https://sourceforge.net/p/wsjt/wsjtx/ci/master/tree/Network/NetworkMessage.hpp

in the commentary at the top. This file may be updated at any WSJT-X public release so authors of interoperating applications should monitor the history of this file for changes at those times if they wish to track any recent changes. No C++ knowledge is required as the commentary has all the information you need, or hyperlinks to further reading for it.

73
Bill
G4WJS.


locked Re: Error: Unable to send a datagram UDP server 127.0.0.1:2237

Bill Somerville
 

On 22/11/2020 04:57, Michael Brower via groups.io wrote:
I had this same issue. My firewall was blocking that port. Once I stopped the blocking of that port everything worked as it was suppose to, also running Mac OS Big Sir  11.0.1
Hi Michael,

I did wonder if it may be a firewall issue but why is a firewall blocking traffic on the local loopback network interface? The Apple macOS standard firewall does not even show the loopback interface. What firewall product are you using?

73
Bill
G4WJS.


Re: WSJT-X with IC-7000, Ubuntu, mhuxd, and a Digi Keyer II

Bill Somerville
 

On 21/11/2020 21:59, sd_wireless via groups.io wrote:
I am trying to get WSJT-X working with an IC-7000, Ubuntu, mhuxd, and a Digi Keyer II. At this point, rig control seems to be working fine. Where I am having problems is with audio.

One oddity I've noted appears to be driven by the choice of the "Rig" on the "Radio" tab. When I am running WSJT-X on Windows I select "Ham Radio Deluxe" as the "Rig" and the "Transmit Audio Source" on the "Radio" tab is available to me.

When I am running Ubuntu I am selecting "ICOM IC-7000" as the "Rig" and the "Transmit Audio Source" on the "Radio" tab is grayed and selected to "Front/Mic". The Digii Keyer II is also telling me the Mic is selected as the audio source. I know this because the "Line" light on the front of the device is flashing. When "Rear/Data" is selected (running on Windows and using HRD) the light is solid red, indicating the audio source is the rear data port.

Is there any way to get WSJT-X to allow me to select the "Rear/Data" port when the "Rig" is set to "ICOM IC-7000"?

Note, the behavior of WSJT-X and the Digi Keyer do not change regardless of the "Mode" setting on the IC-7000. They both function the same regardless of whether USB or RTTY are selected on the radio.
OM,

Icom radios do not have a regular CAT command to select the Tx audio source, it is normally dependent on rig menu settings and sometime on the mode selected (e.g. USB-DATA if available). The Tx audio source options in WSJT-X are enabled for rigs that have a different TX CAT command for different audio sources. These CAT commands are found on a few Kenwood rigs. With HRD as a rig control intermediary we do not concern ourselves what the rig being controlled is so we must allow for source selection whether it be functional or not.

73
Bill
G4WJS.

2241 - 2260 of 20770