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]>
Date: Mon, July 20, 2020 4:09 pm
To: WSJT software development <[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?
MikeK7MDL
Sent from my T-Mobile 4G LTE Device
From: [email protected] <[email protected]>
Sent: Monday, July 20, 2020 12:46:50 PM
To: WSJT software development <[email protected]>
Subject: Re: [wsjt-devel] Feature RequestThank 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!
--alWB1BQE
-------- Original Message --------
Subject: Re: [wsjt-devel] Feature Request
From: Bill Somerville <[email protected]>
Date: Mon, July 20, 2020 12:59 pm
To: [email protected]
On 20/07/2020 17:29, [email protected] wrote:
HI Folks,
I've been lurking in read-only mode for a while here, and just upgraded to 2.2.2 up on my Atomic-Pi. Building the code was simple and all works well.
I was wondering if I could ask for 2 feature requests as time permits, please?
1) user_hardware: (I understand this is currently temporarily broken) Looking at the code, it seems that this feature was implemented only for WSPR but not for some of the other sub-modules within the program. My request is two-fold. First, Please consider calling this script at any mode or band change program-wide.
Secondly, in addition to the band information, if additional information could be included in the calling arguments, (Mode, Band and Frequency) this would be extremely helpful, and might help forstall other feature requests since folks would be able to implement more powerful side functionality.
In my case, I have been using an FT736r for the "JT Modes", however I also use the same rig for satellite use, repeater use etc. (I do this via a very old piece of code called FT-7361 which I dragged kicking and screaming into this century... :) With FT-7361, I can schedule the radio to do various things at various times and if I could get the above requested parameters, would bypass hamlib altogether for this particular use case. The end result would be WSPR during the day, automatically shifting to satellite use at certain times, and listening to my local repeater during commute hours. IN this case, WSJTX becomes a client, rather than the master of the relationship with the radio.
2) My second feature request is to allow certain callsigns to be excluded from the list of stations that are displayed during decode. The use case here is that on 6 meters, many of the local stations call CQ repeatedly all day, essentially causing other interesting dx to scroll off the screen. Being able to filter at least their cq calls would make it easier to see when the band opens to interesting places.
Thanks for any consideration!
--alWB1BQEHi Al,for your second request: as you are running on Linux; have you considered a simple command line in a terminal like:tail -f ~/.local/share/WSJT-X/ALL.TXT | grep -v '\(WB1BQE\|W1LOCAL\)'Add what what you wish to filter to the grep inverse regexp alternation.
73
Bill
G4WJS.
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
