Hi Tom,
firstly, to be clear, the applications that interoperate with WSJT-X
instances are the servers, WSJT-X instances are the clients in this
relationship.
If one or more servers are listening for clients (WSJT-X instances) on a
multicast group address, then each WSJT-X instance you wish to
interoperate with those servers must specify the multicast group address
those servers are in.
For example one or more servers might be set up to join the multicast
group address 239.255.0.0 and listen for UDP traffic on service port
2237. In each WSJT-X instance you would specify
"Settings->Reporting->UDP Server->239.255.0.0" and leave
"Settings->Reporting->UDP Server port number" as 2237.
It is up to you, the user, to choose and set up a suitable multicast
group address, as above, for this scenario.
73
Bill
G4WJS.
On 30/07/2020 13:40, Thomas Schaefer wrote:
So just to be clear, if the clients support Multicast, I should put
239.255.0.1 as the address in WSJT-X rather than 127.0.0.1, correct?
I have seen a few different addresses mentioned in my research.
Thanks,
Tom Schaefer, NY4I
Blog: www.ny4i.com <http://www.ny4i.com>
Madeira Beach, FL (Grid: EL87ot)
On Jul 30, 2020, at 7:47 AM, Sam W2JDB via wsjt-devel
<[email protected]
<mailto:[email protected]>> wrote:
Hi Bill,
Just an FYI, I have tested multicast (239.255.0.1) with QLog and
GridTracker both listening to WSJT-X UDP traffic without any problems.
73,
Sam W2JDB
-----Original Message-----
From: Saku <[email protected] <mailto:[email protected]>>
To: [email protected]
<mailto:[email protected]>
Sent: Thu, Jul 30, 2020 4:33 am
Subject: Re: [wsjt-devel] ERE: Feature Request
HI Al and Bill!
I made quick test to enable multicast with cqrlog wsjt-remote.
(Ararat Synapse is used in wsjt-remote)
Now doing multicast initialization if ip address is from cqrlog
preferences is from 239.0.0.0/8 subnet.
Seems to work, but needs further testing that it really does. (I need
some other stuff to listen the address at same time).
If it is ok I will request it to cqrlog after test period. (Source
now in my GitHub https://github.com/OH1KH/cqrlog/tree/multi_wsjtx)
Bill Somerville kirjoitti 26.7.2020 klo 23.40:
Hi Al,
try 239.255.0.0.
73
Bill
G4WJS.
On 26/07/2020 21:34, [email protected] <mailto:[email protected]>
wrote:
Thanks, Bill - this may be what I needed.
Both wsjtx and cqrlog have a place to specify an address. I'm
currently using 127.0.0.1. I can go see if there is a multicast
specification that I can put in here.
--al
WB1BQE
-------- Original Message --------
Subject: Re: [wsjt-devel] ERE: Feature Request
From: Bill Somerville <[email protected]
<mailto:[email protected]>>
Date: Sun, July 26, 2020 3:45 pm
To: [email protected]
<mailto:[email protected]>
Hi Mike,
applications that interoperate with WSJT-X using the UDP
protocol are supposed to support listening on a UDP multicast
group address, this allows multiple applications to listen on
the same port and each have all messages delivered to them.
Unfortunately several applications have not included multicast
support, either because they use tools that don't easily support
it, or they didn't see the need.
73
Bill
G4WJS.
On 26/07/2020 20:34, [email protected]
<mailto:[email protected]> wrote:
HI Mike (and everybody else),
I was fascinated by your idea of using the UDP status
messages, but wanted to put together a POC and get past the
initial teething pains before making more noise. Today the
lawnmower broke, providing me such an opportunity... :)
As of now, I have a simple Python script (Borrowed heavily
from an internet tutorial on UDP. It connects to wsjtx 2.2.2,
and outputs blocks of data as exppected. From the ascii
portions, I recognize this as part of the block described in
the communication protocol, so in theory, I should be able to
parse this apart and get what I need.
I did, however, hit a snag. I also use CQRLOG for
automatic logging. Apparently CQRLOG also uses this
integration, because I get an address in use error if Imy
script tries to connect while CQRLOG is running. (it works
fine otherwise, as outlined above.)
Fine points of networking aren't really my thing, but I like
to learn stuff. That said, before I go down a potentially bad
path, at the block diagram "architectural" level, is it
possible for 2 clients to share a UDP port, or is the desire to
also have CQRLOG running a deal breaker?
(I tried the secondary port (2233), but that appears to be
only logged data, not the treasure trove that is on port 2237.)
Thanks for any guidance!
--al
WB1BQE
-------- Original Message --------
Subject: Re: [wsjt-devel] Feature Request
From: Mike Lewis <[email protected] <mailto:[email protected]>>
Date: Mon, July 20, 2020 4:09 pm
To: WSJT software development
<[email protected]
<mailto:[email protected]>>
I use a Python program to monitor the WSJT-X UDP status
message broadcasts. It has radio dial frequency and more.
I use the frequency to load the correct calibration data
for my remote VHF+ wattmeter. It in turn can be used to
drive other things.
The wattmeter is a Arduino or PSoC5 device attached to a rf
log detector and standard dual directional coupler.
It would seem the UDP status message has all you would need?
Mike
K7MDL
Sent from my T-Mobile 4G LTE Device
Get Outlook for Android <https://aka.ms/ghei36>
------------------------------------------------------------------------
*From:* [email protected] <mailto:[email protected]>
<[email protected] <mailto:[email protected]>>
*Sent:* Monday, July 20, 2020 12:46:50 PM
*To:* WSJT software development
<[email protected]
<mailto:[email protected]>>
*Subject:* Re: [wsjt-devel] Feature Request
Thank you Bill (And Bill) - that worked great and does
exactly what I was looking for! (In fact, I can feed it to
Python's simple webserver and watch for DX from anywhere... :)
I'm also going to try WB6DJI (Mike's) suggestion of JTDX.
I would really love it if the user_hardware request saw
the light of day at some point. I currently have 2
Raspberry PI / SDR combos which band hop on wspr all day,
but if I could get some extra data passed in around the
wsjt-x operating mode, and the frequency, I could do a lot
in terms of integrating the FT-8 setup into the rest of my
shack so it can drive my network aware antenna switches etc.
73, and thanks!
--al
WB1BQE
_______________________________________________ wsjt-devel mailing
list [email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
--
Saku
OH1KH
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
