[wsjt-devel] wsjt FH vs. clone's
Hi there, Please forgive me if you find this irrelevant. I can't resist: Why it matters (at least for me): A DX-pedition is tx-ing and I "need" this country for my DXCC (or whatever). He runs F/H with WSJT-X. I get through within 3 to 4 calls. Happy bunny, I log the QSO. He runs a clone. I never get through! What to watch: I have got a report from ZL7IO within 10 min calling from EU. believe me: ZL7 from EU is NOT easy. I could not get a report from 5B4AMX (a neighborough of sort) using a clone althought I called many times! Please DX-peditionners, ALWAYS USE F/H, it is far far more efficient than anything else! Cheers Serge ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] ANNOUNCEMENT: update_wsjtx_log.py version 1.1.1 released
I cannot agree more This subject deserves its own environment. Please keep it away from the devel list 73, Serge On 08/03/2021 23:13, Joe Taylor wrote: Hi Dave, I was not looking for confrontation, at all. Just looking to help you and all readers of this list to have convenient access to the information you're most interested in, on the appropriate list. -- 73, Joe, K1JT On 3/8/2021 2:21 PM, Dave Slotter, W3DJS wrote: K1JT: Are you stating this as a personal opinion, or as the moderator of the wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> mailing list? -- Dave Slotter, W3DJS <https://www.qrz.com/db/W3DJS> On Mon, Mar 8, 2021 at 1:38 PM Joe Taylor <mailto:j...@princeton.edu>> wrote: Hi all, Perhaps it's time to move discussion of "update_wsjtx_log.py" onto another email list. Other WSJT-related software, including derivative programs (JTDX, MSHV, JS8Call, ...) as well as cooperative programs (JTAlert, ...) have their own lists, and these distinctions serve all users well. As its name suggests, the wsjt-devel email reflector is devoted to development of WSJT(-X) and its immediate sister programs. -- 73, Joe, K1JT ___ 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 DEYRAS, JN24IX, ARDECHE ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] No TX1, no chocolate
A reminder to those of us using non-standard call: When you don't use TX1 you don't make QSO 190130 Tx 2712 ~ EA3BCX F6BHK JN24 190115 -3 0.3 2426 ~ F6BHK <...> 190215 -7 0.2 2436 ~ F6BHK <...> 190300 -11 0.9 1490 ~ CQ IT9DBN JM77 -- 73, de Serge F6BHK, ex-VR2LL, G5BHT, FM5GC DEYRAS, JN24IX, ARDECHE ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Suggestion
Hi Joe, Thank you for your answer. Cheers Serge On 09/08/2019 00:36, Joe Taylor wrote: Hi Serge, On 8/8/2019 17:31, Serge F6BHK wrote: at the dawn of WSJT-X we had the choice to decode JT65+JT9 under the same combo value. I remember I found it very useful. When I double-clicked a JT65 signal then I was sending using JT65, same for JT9. would'nt it be nice to have a FT8+FT4 combo value that decode both of the protocols and set the Xmit side of WSJT-X accordingly? Because their T/R sequence lengths are different, FT4 and FT8 are not amenable to the convenient dual-mode decoding scheme that was useful for JT65 and JT9. -- 73, Joe, K1JT ___ 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 DEYRAS, JN24IX, ARDECHE ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Suggestion
Hi all! at the dawn of WSJT-X we had the choice to decode JT65+JT9 under the same combo value. I remember I found it very useful. When I double-clicked a JT65 signal then I was sending using JT65, same for JT9. would'nt it be nice to have a FT8+FT4 combo value that decode both of the protocols and set the Xmit side of WSJT-X accordingly? Just a suggestion Cheers Serge -- 73, de Serge F6BHK, ex-VR2LL, G5BHT, FM5GC DEYRAS, JN24IX, ARDECHE ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] UDP message type 4 on RR73 message
Thanks Bill for your answer GN 73 Serge On 31/07/2019 22:10, Bill Somerville wrote: On 31/07/2019 20:56, F6BHK wrote: Can someone confirm it's part of the dev team fight against automated robot or a misunderstanding from my own? Hi Serge, your assumption is correct. 73 Bill G4WJS. ___ 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 DEYRAS, JN24IX, ARDECHE ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] FT4 bug/oddity.
It's not a bug. Just a false decode On 31/07/2019 21:11, Topher Petty wrote: I had an interesting one today... Got a call from 2W2UHM/P grid square RA74 (I know, unlikely), which terminated oddly... By "terminated oddly" I mean the station "called" me, the software auto-replied RR73, and the log window popped up... I went ahead and logged it, "just in case", but.. it's still odd... Attached is the screenshot and a copypasta of the logged contact. Not really sure what happened here, where the signal reports came from, or any of that... Unfortuately, I wasn't saving .wav files at the time. 2W2UHM/P RA74 MFSK FT4 -13 -04 20190731 174731 20190731 174745 20m 14.081654 AI8W EN82JG FT4 50W Sent: -13 Rcvd: -04 image.png ___ 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 DEYRAS, JN24IX, ARDECHE ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] UDP message type 4 on RR73 message
Howdy ? Long time no email ;-) The doc says UDP type 4 is as if I double clicked into the Band Activity window. It is correct when the message is a CQ or a QRZ as highlighted into NetworkMessage.hpp file. When I double click on a message "foo fuu RR73" in the Band Activity window, WSJT-X put the line into the RX Frequency window, prepare the message with fuu and send the appropriate CAT commands to call fuu. Allright. But when I send a UDP type 4 message for this very same "foo fuu RR73", WSJT-X put the line into the RX Frequency window, prepare the message with fuu and DO NOT send CAT commands so I don't call fuu. Too bad! It looks like a failure or a refusal to act (please Freud: forgive me...) Or I miss something somewhere. Can someone confirm it's part of the dev team fight against automated robot or a misunderstanding from my own? Thank you Cheers Serge -- 73, de Serge F6BHK, ex-VR2LL, G5BHT, FM5GC DEYRAS, JN24IX, ARDECHE ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Another observed drawback - audio input level
Please be considerate of others. We don't speak or understand english
very well but are venting our ideas on this list in good faith.
Else simply delist all foreigners
73
Serge F6BHK
On 30/04/2019 21:10, Joe Taylor wrote:
Please read messages to the list before sending your own on the same
topic!
Please read the announcement abou -rc5:
"Windows users will discover that WSJT-X v2.1.0 has been made
available as a 64-bit MS Windows build for 64-bit versions of Windows
since Vista. This version has one known defect. The audio input device
level will be reset to 100% when WSJT-X is started, when the input
audio device is changed, and when switching to a new configuration.
This is a Qt framework defect that we have reported and is being fixed
in a future release; until then users should take care to set the
device audio level back to 0dB or lower depending on requirements.
Note that many sound cards and chips have real gain ahead of the ADC,
as much as 14dB, which will be turned to the maximum due to this
defect and is usually undesirable when using WSJT-X.
"Despite this annoying defect, we recommend the 64-bit version of
WSJT-X on MS Windows as it has significant advantages in decoding speed."
-- 73, Joe, K1JT
On 4/30/2019 14:53, Enrique Scheuer wrote:
Same problem here with the same operational conditions.
de Enrique
PY2CP
Em ter, 30 de abr de 2019 às 15:31, Paul Kube <mailto:paul.k...@gmail.com>> escreveu:
Looking at this ("Microphone Properties" for the USB Audio Codec
that the IC-7300 provides and that WSJT-X uses as input):
miclevel.png
It gets set to 100% whenever WSJT-X 2.1.0-rc5 starts, and I have to
set it to 40% "by hand". WSJT-X 2.0.1 did not have this issue.
Windows 10 Pro x64 here.
73, Paul K6PO
On Tue, Apr 30, 2019 at 5:48 AM Black Michael via wsjt-devel
mailto:wsjt-devel@lists.sourceforge.net>> wrote:
Are you guys looking at the dB level in the audio management
panel? Or the % level?
WSJT-X does not touch the audio so it has to be Windows doing
it.
Recording audio should be at 0dB.
de Mike W9MDB
On Tuesday, April 30, 2019, 6:55:30 AM CDT, kf8my--- via
wsjt-devel mailto:wsjt-devel@lists.sourceforge.net>> wrote:
It also does it in Win7, audio sound recording to max on
restart.
Mike/kf8my
-Original Message-
From: Joe, LB1HI mailto:jo...@lb1hi.no>>
To: wsjt-devel mailto:wsjt-devel@lists.sourceforge.net>>
Sent: Tue, Apr 30, 2019 6:46 am
Subject: [wsjt-devel] Another observed drawback - audio input
level
Hi,
Another observed drawback is that after each WSJT-X restart,
previously
pre-set audio (Win 10 64 bit) signal input level of the sound
card
changes. It changes spontaneously. It changes to a maximum -
100% of
the level setting range.
73`s Joe
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
<mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
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
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Add generic webservice client to the QSO send program.
You don't answer Jim's questioning. Besides, Bill gave you a quick view on UDP msg. And I cannot agree more. UDP msg give us all what we need to know about WSJT insides. Why would we need something else? 73 Serge On 14/03/2019 12:19, Bastien F4EYQ wrote: On 2019-03-13 17:59, Jim Brown wrote: On 3/13/2019 7:11 AM, Bastien F4EYQ wrote: I've develop a "Radio Cloud" for ham people, This cloud purpose a logbook "online" LOTW and eQSL work quite well. Why do we need another one? 73, Jim K9YC ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel Hello Jim, A quote is always better than a bad answer : "We always have the choice. We are indeed the product of our choices." Joseph O'Connor 73 Bastien. ___ 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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] F/H sequence
The line that contains RR73 suggest you were not in F/H but in QSO with a JTDX user. This is a WSJT-X clone with some mods one of which being to merge RR73 to previous QSO with report for the next QSO. 73, Serge On 13/03/2019 23:36, Steven Franke via wsjt-devel wrote: Hi Pino, You called the DX on 1321 Hz offset. Then, the DX responded to you with report +00. If you were operating as a Hound, then your next transmission should have been at 303 Hz. Instead, you transmitted your “R-20” again at 1321 offset. This behavior suggests that you were not operating as a “Hound”. Can you verify that you had selected “Hound” and that “Special operating activity” was checked? 73 Steve, k9an On Mar 13, 2019, at 5:11 PM, Pino Zollo <mailto:pinozo...@gmail.com>> wrote: Wrong sequence: WSJT 2.0.1 does not realize having received RR73 and replies with R-20 I had to force by hand the 73 I have seen this fact 3 times with different F/H stations. 73 Pino ZP4KFX 20415 Tx 1321 ~ 7P8LB ZP4KFX GG14 220430 -20 0.0 303 ~ ZP4KFX 7P8LB +00 ? a3 220445 Tx 1321 ~ 7P8LB ZP4KFX R-20 220500 -18 0.0 303 ~ DK6IM 7P8LB -17 220515 Tx 1321 ~ 7P8LB ZP4KFX R-20 220530 -18 0.5 302 ~ ZP4KFX RR73; DK6IM <7P8LB> -18 220545 Tx 1321 ~ 7P8LB ZP4KFX R-20 220548 Tx 1321 ~ 7P8LB ZP4KFX 73 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ 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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] probably another hash mixup
Hi there Well, It might be of help: another hash mixup issue probably. No answer needed. Here is the QSO 225200 0 -1.3 2868 ~ CQ JT/PD0LK 225217 Tx 2868 ~ F6BHK 225245 Tx 2868 ~ F6BHK 225300 -3 -1.3 2868 ~ F6BHK -08 225315 Tx 2868 ~ F6BHK 225330 -8 -1.3 2868 ~ JT/PD0LK RRR 225415 Tx 2868 ~ JT/PD0LK 73 looks like JT/PD0LK and EB8AC collide. For what it's worth Cheers Serge -- 73, de Serge F6BHK, ex-VR2LL, G5BHT, FM5GC PUY SAINT MARTIN, 26 DROME, FRANCE JN24LP ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] strange non-qso
Thanks Bill. Understand. Merry Xmas Cheers Serge On 25/12/2018 17:23, Bill Somerville wrote: On 25/12/2018 15:29, F6BHK wrote: 151630 -17 0.4 1694 ~ CQ 4X19HNY 151646 Tx 1694 ~ <4X19HNY> F6BHK 151715 Tx 1694 ~ <4X19HNY> F6BHK 151730 -17 0.4 1694 ~ F6BHK <4X19HNY> -22 151745 Tx 1694 ~ <4X19HNY> F6BHK R-17 151815 Tx 1694 ~ <4X19HNY> F6BHK R-17 151800 -22 0.4 1693 ~ F6BHK <4X19HNY> -22 151816 Tx 1694 ~ <4X19HNY> F6BHK R-22 151845 Tx 1694 ~ <4X19HNY> F6BHK R-22 151900 -19 0.3 1693 ~ <...> 4X19HNY RR73 151915 -16 1.1 1694 ~ <4X19HNY> SQ2BNM -15 in the sense I am not able to be sure 4X19HNY has got my report. I would have expected <...> being instead. Hi Serge, this is another variant on the known issue with hash collisions in WSJT-X v2.0.0. In this case the first message you receive with your callsign hashed: 151900 -19 0.3 1693 ~ <...> 4X19HNY RR73 is not printed correctly because WSJT-X has not stored your own callsign in the relevant hash table (not a hash collision but a missing hash code mapping to you callsign). Although it is not clear you can be quite certain that 4X19HNY has copied your call correctly since it was sent in full during the QSO in the message: 151730 -17 0.4 1694 ~ F6BHK <4X19HNY> -22 I would log the QSO as it almost 100% certain that the sign off message sent by 4X19HNY was " 4X19HNY RR73" and it will be in his log. This issue is resolved for the next release of WSJT-X. 73 & Merry Christmas Bill G4WJS. ___ 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 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] strange non-qso
Dan Thank you for your answer, however my questioning is on the software side, not on the call itself. With the following messages from WSJT-X, I feel - I can be wrong, but - I feel that I cannot decide whether the QSO is completed or not completed. See, the last message I read from the 4X station is not clear as to whether this message is for me or for someone else. 73 Serge On 25/12/2018 17:14, Dan Malcolm wrote: A search of QRZ found 4X19HNY and there is a pointer to their live log on that page. __ Dan - K4SHQ -Original Message- From: F6BHK [mailto:f6...@f6bhk.org] Sent: Tuesday, December 25, 2018 9:30 AM To: WSJT software development Subject: [wsjt-devel] strange non-qso Merry Xmas to all! The following QSO seems to me "strange": 151630 -17 0.4 1694 ~ CQ 4X19HNY 151646 Tx 1694 ~ <4X19HNY> F6BHK 151715 Tx 1694 ~ <4X19HNY> F6BHK 151730 -17 0.4 1694 ~ F6BHK <4X19HNY> -22 151745 Tx 1694 ~ <4X19HNY> F6BHK R-17 151815 Tx 1694 ~ <4X19HNY> F6BHK R-17 151800 -22 0.4 1693 ~ F6BHK <4X19HNY> -22 151816 Tx 1694 ~ <4X19HNY> F6BHK R-22 151845 Tx 1694 ~ <4X19HNY> F6BHK R-22 151900 -19 0.3 1693 ~ <...> 4X19HNY RR73 151915 -16 1.1 1694 ~ <4X19HNY> SQ2BNM -15 in the sense I am not able to be sure 4X19HNY has got my report. I would have expected <...> being instead. 73 Serge -- 73, de Serge F6BHK, ex-VR2LL, G5BHT, FM5GC PUY SAINT MARTIN, 26 DROME, FRANCE JN24LP ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] strange non-qso
Merry Xmas to all! The following QSO seems to me "strange": 151630 -17 0.4 1694 ~ CQ 4X19HNY 151646 Tx 1694 ~ <4X19HNY> F6BHK 151715 Tx 1694 ~ <4X19HNY> F6BHK 151730 -17 0.4 1694 ~ F6BHK <4X19HNY> -22 151745 Tx 1694 ~ <4X19HNY> F6BHK R-17 151815 Tx 1694 ~ <4X19HNY> F6BHK R-17 151800 -22 0.4 1693 ~ F6BHK <4X19HNY> -22 151816 Tx 1694 ~ <4X19HNY> F6BHK R-22 151845 Tx 1694 ~ <4X19HNY> F6BHK R-22 151900 -19 0.3 1693 ~ <...> 4X19HNY RR73 151915 -16 1.1 1694 ~ <4X19HNY> SQ2BNM -15 in the sense I am not able to be sure 4X19HNY has got my report. I would have expected <...> being instead. 73 Serge -- 73, de Serge F6BHK, ex-VR2LL, G5BHT, FM5GC PUY SAINT MARTIN, 26 DROME, FRANCE JN24LP ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Question on UDP message in v2
clear. thanks a million Bill for the info. cheers serge Envoyé de mon iPad > Le 13 déc. 2018 à 19:16, Bill Somerville a écrit : > >> On 13/12/2018 17:37, F6BHK wrote: >> Hello, >> >> A quick question on "Status" UDP messages sent by WSJT-X v2. >> >> WSJT sent me a message where the length of the DXCall is -1. This is new for >> me: I didn't notice this behavior in v 1.9.1. >> >> Here is an example of the frame after a conversion to hex : >> >> [000b57534a542d58202d207632009aa9c346543800032d313500034654380105dc05dc0005463642484b00064a4e3234697800] >> >> >> See after the mode (FT8) I have , then follows the report in UTF8 >> format. >> >> It looks to me I should have received a UTF8 string instead of . >> Well I might have misinterpreted the NetworkMessage.hpp contents where >> DXCall is UTF8 formatted between the mode and the report. >> >> Or is it a way to deal with empty string? >> >> Thanks for your help >> >> Cheers >> >> Serge > > Hi Serge, > > as documented here http://doc.qt.io/qt-5/datastreamformat.html the > serialization of a QString variable can have a length of 0x (it is > unsigned) and that signifies a null value. You may wish to treat zero-length > and null strings as equivalent as mentioned in the documentation here: > https://sourceforge.net/p/wsjt/wsjtx/ci/master/tree/NetworkMessage.hpp#l42 in > the second paragraph down. > > A null or empty DX Call field in s a status update simply means the DX Call > field is empty or has just been cleared. > > 73 > Bill > G4WJS. > > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Highlighting calls in WSJT-X
Hello. Thanks to Saku, OH1KH, I am able to add colours to the Band Activity window of WSJT-X. The colours change with criteria such as new DXCC, per band or all time, etc. It works perfectly well. Thanks a lot for that. Now, I use also the line highlighting from settings->Colors. Because I modify the bg colour when highlighting calls through UDP messages, the line is frequently painted with different bg colours, and that is neither nice to see nor useful... but it is eyes catching! My question: is there a way to set the line bg colours by the UDP type 13 message? Also, it seems to me that calls highlighted remain highlighted on band change. This fails the objective of DXCC per band signalisation. My question: is there an option/checkbox somewhere that would reset all the colours set to default values when changing band or mode? Thank you for your answers. Keep up the good work! Cheers Serge -- 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
[wsjt-devel] Highlight call: would need some help
Hi there, Again, I am in the dark. I serialised a UDP frame from my server to WSJT-X as below: > adbccbda0002000c000657534a542d5800054c5831484400ff00ad00ff00 This frame is sent to WSJT-X in order to: Highlight the call LX1HD in colour #00ad00 with alpha = 1 on a background #00 with alpha = 1. Of course, the frame is sent as a binary string. The representation above has been translated into hex so as to be printable. I must do something wrong… I don’t know what! Any feedback welcome Cheers Serge-- 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] Build wsjt-x on Debian
Hi there, I successfully built wsjt-x on Debian Stretch yesterday. The existing INSTALL file is not up-to-date. You guys might be interested by the steps I had to go through in order to build wsjt-x. Starting from a fresh Stretch install (Debian 9.4): (apt-get update + upgrade + dist-upgrade Stretch) I could not find build-essentials in the repo (I seem to remember that name but that was a very long time ago), so I had to: apt-get install gcc g++ fortran cmake (lowercase; CMake does not exist) texinfo libtool automake (autoreconf is not a package) apt-get install git subversion (svn is not a package) asciidoc asciidocto pkg-config apt-get install qt5.7 qt5libmultimedia-dev qt5widgets qt5base5-dev qtmultimedia5-dev libqtseriqlport5 lib5qt5serialport5-dev apt-get libudev-dev libusb-1.0-0-dev fftw3-3-dev libfftw3-dev default versions of gcc/g++ is gcc6. When you local repo is updated, then (as detailed in the INSTALL) get source: wget —no-ckeck-certificates https://physics/wsjtx-1.9.0-rc4.tgz and untar in your build: cmake —build install cmake —build —target install et hop ! done (it took a night to a "VIA Epia" cell with 1Gb mem and 500Gb disk to complete) There is a big load of warnings when compiling the fortran source files but I saw something about that on the reflector some days ago. Cheers Serge -- 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] Second Public Test of FT8 DXpedition Mode: April 7, 1400-1600 UTC
Hi there I found the use of the "Ping Jockey Relief" chat page was a very good idea, and useful and working well! I was able to hear steadily the first fox W1/KH7Z. Gave him a series of call from 1402 Z (since the fox was late... never saw this case in real life - I share my sofa with 2 Spanish greyhounds - galgos - and the rabbits always hope the hounds will be late) till 1410 Z to no avail. I had put my TX above 3500Hz; nobody was TXing up there. Then from 1410 till 1430 I tries to move my freq between 2500Hz and 4000Hz. That led me to nowhere. Then the bugs hit the fox and he gave up. Too bad, for I never heard his Stand-in partner. As for the W7/KH7Z fox, I never ever heard him calling. I guess the propag was not top level and my low range station (Flex 5000A running abt 90W max into a vertical R7) was not efficient enough to get my signal cross half our world. But I stayed listening. I find that I heard a lot of people calling and sending reports, however I find that the number of RR73 were not as numerous as they should have been. I was surprised to "see" in the waterfall the fox's sigs (up to 'yellowish' dots) whilst there were no decode at all. All in all a very frustrating experience, I hope it'll be for the good! Cheers Serge -- 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] Premature use of FT8 DXpedition Mode
We are all experimenters. Give us a tool that is new and we will use it and shake it until it exhauts. You know we would use the DXp side of WSJT-X as soon as you released it. Because it's new, because it's shining, because it's what we expected, because we don't know what to expect but we are curious. Comme on: you release the monster... now you know that we will not listen to reason: it is your responsibility to limit the effect of the beast, for your developers' team has got the means to do it. Now, I shall be on the aire on April 7th to shake the ether. See ya Serge On 29/03/2018 21:15, Joe Taylor wrote: Everyone paying attention should already know what's contained in this message -- but it's clear that some do not. The current General Availability (GA) release of WSJT-X is v1.8.0. That program version does not include FT8 DXpedition Mode. We have made beta-level "release candidates" available for the explicit purpose of testing FT8 DXpedition Mode. The release candidates have included cautionary warnings to the effect that in its present form, DXpedition Mode should be used only for controlled testing. A few operators or groups have ignored our warnings and tried to use FT8 DXpedition Mode in true pileup situations. The consequences are predictably bad -- especially when the offending operator(s) have chosen their frequencies badly and other operators are using a mix of program versions including v1.8.0, v1.9.0-rc2, v1.9.0-rc3, some version of JTDX. FT8 DXpedition Mode is not yet ready for “production” use. Until WSJT-X v1.9.0 is fully released -- not a beta-level "release candidate", but a full General Availability release -- DXpedition Mode should be used only in controlled test situations. The next public test of FT8 DXpedition Mode conducted by the WSJT Development Group will be conducted on April 7, a little over a week from now. You are cordially invited to join us for this test. See the announcement posted here yesterday (Subject: WSJT-X v1.9.0-rc3: Testing of FT8 DXpedition Mode) for details. -- 73, Joe, K1JT -- 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] Premature use of FT8 DXpedition Mode
And about the expedition using DXp without the authorization of the development team (and who did not read the readme file either): I find, for one, that they are doing a very good job. They found how to publicize their expedition (freq and time), and, with the number of bugs in the app, they manage to give a significant number of ham reports. look to me people you should ask how they did it! Just in case you are walking down an improvement process. Cheers Serge On 29/03/2018 21:15, Joe Taylor wrote: Everyone paying attention should already know what's contained in this message -- but it's clear that some do not. The current General Availability (GA) release of WSJT-X is v1.8.0. That program version does not include FT8 DXpedition Mode. We have made beta-level "release candidates" available for the explicit purpose of testing FT8 DXpedition Mode. The release candidates have included cautionary warnings to the effect that in its present form, DXpedition Mode should be used only for controlled testing. A few operators or groups have ignored our warnings and tried to use FT8 DXpedition Mode in true pileup situations. The consequences are predictably bad -- especially when the offending operator(s) have chosen their frequencies badly and other operators are using a mix of program versions including v1.8.0, v1.9.0-rc2, v1.9.0-rc3, some version of JTDX. FT8 DXpedition Mode is not yet ready for “production” use. Until WSJT-X v1.9.0 is fully released -- not a beta-level "release candidate", but a full General Availability release -- DXpedition Mode should be used only in controlled test situations. The next public test of FT8 DXpedition Mode conducted by the WSJT Development Group will be conducted on April 7, a little over a week from now. You are cordially invited to join us for this test. See the announcement posted here yesterday (Subject: WSJT-X v1.9.0-rc3: Testing of FT8 DXpedition Mode) for details. -- 73, Joe, K1JT -- 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
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
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
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
[wsjt-devel] Request for the mod of UDP type 4 message
Hello dear developers, 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 -- 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
[wsjt-devel] SOLVED: Difficulties to get WSJT-X to accept UDP type 4 message from server
Good day, My server works in sync with WSJT-X now. My mistakes might be of interest for others, so I wish to share this conclusion with you. First of all, I wish to thank David, Laurie VK3AMA, Brian and Bill G4WJS for their suggestions to my previous messages. They gave me feedbacks that made me identify 4 mistakes. A brilliant demonstration of team value! - First one was a misuse of QTime type: at one line of my code I had forgotten that QTime is NOT Unix time. - Second a mix-up of hex code in utf8 where ascii was expected. - Third a complete misunderstanding of this sentence: "the message exactly describes a prior decode" that lead me to substitute the CQ in the DECODE message by my call. I should not have modified the message text. - Last was the socket sendto sending to the multicast address instead of the client IP address. I was expecting WSJT-X to listen for diagrams on the multicast group. Thank a lot again for the efficient help. Cheers Serge -- 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
[wsjt-devel] More on Difficulties to get WSJT-X to accept UDP type 4 message from server
I have digged deeper in my problem: a) Network infra: The server uses a multicast group. There is no router between the WSJT-X client and the server; only a switch. I have verified with tcpdump on both sides that the packet are seen by both camps. b) I have written a quick PHP client that I have plugged on the same network as the server and the WSJT-X client. The server and the PHP client establish a 2 way dialog with no pain. The WSJT-X client stays deaf. However it speaks as expected. For example, I receive this DECODE message from WSJT-X: 2018/03/22 20:07:59 server.php - Received 66 bytes from remote IP: 192.168.60.53:63580 2018/03/22 20:07:59 server.php magic binary : [adbccbda] 2018/03/22 20:07:59 server.php schema binary : [0002] 2018/03/22 20:07:59 server.php type of message binary : [0002] 2018/03/22 20:07:59 server.php DECODE id : [0006: WSJT-X] 2018/03/22 20:07:59 server.php DECODE new : [01] 2018/03/22 20:08:00 server.php DECODE time : [72465000 -> 20:07:45] 2018/03/22 20:08:00 server.php DECODE snr : [ffef -> 0010 -> -17] 2018/03/22 20:08:00 server.php DECODE delta time : [3fd9a000 -> 0.4000596046] 2018/03/22 20:08:00 server.php DECODE delta : [1703 Hz] 2018/03/22 20:08:00 server.php DECODE mode : [0001: ~] 2018/03/22 20:08:00 server.php DECODE message : [000c: CQ K1VK FN42] 2018/03/22 20:08:00 server.php DECODE Low confidence : [00] 2018/03/22 20:08:00 server.php DECODE Off air : [00] The server asks WSJT-X to initiate a response with this message: 2018/03/22 20:08:29 server.php SEND TO WSJT-X id : [00064c4f47474552 size: 0006] 2018/03/22 20:08:29 server.php SEND TO WSJT-X time : [0451ba68 -> 0451ba68 -> 20:07:45] 2018/03/22 20:08:29 server.php SEND TO WSJT-X snr : [ffef -> -17] 2018/03/22 20:08:29 server.php SEND TO WSJT-X deltatime : [3fd9a000 -> 0.4000596046] 2018/03/22 20:08:29 server.php SEND TO WSJT-X delta : [06a7 -> 1703 Hz] 2018/03/22 20:08:29 server.php SEND TO WSJT-X mode : [00017e] 2018/03/22 20:08:29 server.php SEND TO WSJT-X message : [000f4b31564b20463642484b204a4e3234 -> len: 000F -> K1VK F6BHK JN24] 2018/03/22 20:08:29 server.php SEND TO WSJT-X lowconfidence : [00] 2018/03/22 20:08:29 server.php SEND TO WSJT-X modifiers : [00] 2018/03/22 20:08:29 server.php SEND TO WSJT-X frame : [adbccbda0002000400064c4f474745520451ba68ffef3fd9a6a700017e000f4b31564b20463642484b204a4e3234] 2018/03/22 20:08:29 server.php SEND TO WSJT-X frame envoyee : [68 bytes, 239.73.0.0:2237 UDP: 68] WSJT-X ignore the message. But the PHP client decodes it no worries: client.php - FRAME 09 -- client.php - Received 68 bytes from remote IP: 192.168.60.162:2237 client.php magic binary : [adbccbda] client.php schema binary : [0002] client.php type of message binary : [0004] client.php id : [LOGGER] client.php time : [72465000 -> 20:07:45] client.php DECODE snr : [ffef -> 0010 -> -17] client.php DECODE delta time : [3fd9a000 -> 0.4000596046] client.php DECODE delta : [1703 Hz] client.php DECODE mode : [0001: ~] client.php DECODE message : [000f: K1VK F6BHK JN24] client.php DECODE Low confidence : [00] client.php DECODE modifiers : [00] I have read in MessageNetwork.hpp the the id must be the Target unique id. I tried with the WSJT-X client id and with something else to no avail. I have noted a difference between the mode from DECODE message (the letter ~) and the mode from the STATUS message (plain text FT8). None of them awake WSJT-X client. I must say that I could use some help from here! I really am at a loss to understand what goes on here. Any taker ? Cheers Serge On 21/03/2018 19:22, F6BHK wrote: Good Evening While I am able to received and decode all the messages that come out of WSJT-X via UDP, I have some difficulties to get WSJT-X client to accept the server type 4 messages. I have checked in the settings all 3checkboxes "Accept UDP requests", "Notify on accepted UDP request", "Accepted UDP requests restores windows" in the hope to get some feedback from the client. I was expecting some updates on the client window with some of the data contained in the UDP message I send and an acknowledgement and/or an error message. But my messages must be ill-formed, for I get out of WSJT-X nothing except when the UDP message is really, and voluntarily, broken (there is a popup window screaming about bad format). I use version 1.9rc2 on Win7 pro, and this version works like a charm when used manually (I mean with the mouse/keyboard). I have double checked the message format I send and I am pretty confident that it is following the definition in NetworkMessage.hpp Should my expectations be correct, is there a way to get more details about what happens to WSJT-X
[wsjt-devel] Difficulties to get WSJT-X to accept UDP type 4 message from server
Good Evening While I am able to received and decode all the messages that come out of WSJT-X via UDP, I have some difficulties to get WSJT-X client to accept the server type 4 messages. I have checked in the settings all 3checkboxes "Accept UDP requests", "Notify on accepted UDP request", "Accepted UDP requests restores windows" in the hope to get some feedback from the client. I was expecting some updates on the client window with some of the data contained in the UDP message I send and an acknowledgement and/or an error message. But my messages must be ill-formed, for I get out of WSJT-X nothing except when the UDP message is really, and voluntarily, broken (there is a popup window screaming about bad format). I use version 1.9rc2 on Win7 pro, and this version works like a charm when used manually (I mean with the mouse/keyboard). I have double checked the message format I send and I am pretty confident that it is following the definition in NetworkMessage.hpp Should my expectations be correct, is there a way to get more details about what happens to WSJT-X when it gets my message, such as error messages, trace log, etc? I could not find anything on UDP dialog in the User's manual nor did I find a startup option or something else to help me. Thank you for your answers 73, Serge PS: keep up the very good work guys! FT8 is fun! Cheers! -- 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
