Re: [wsjt-devel] Remote WSJT
Splitting the UI and data processing code would mean a major rewrite of the project. It might be much easier to implement some API, e.g. REST-based, for the functions that are currently performed via the UI. Then WSJT-X would run with its main window minimized or hidden on the remote system, and the controlling app with UI would run in the shack. 73 Alex VE3NEA On 2024-02-28 13:12, Rafael Pinto via wsjt-devel wrote: William, You got the architecture right. The point is not having to render images and treat UI events, thus having all processing power for mathematical computation. X Windows System and Wayland are memory and CPU hogs and in some cases those resources are at a premium... As I read the code, trying to figure out how WSTJ-X works, I notice how tightly coupled UI and data processing are. I understand it can be easier to show things on the GUI, but decoupling those could allow for some different UX (text-only, for example) or, as I suggested, some "smart" remoting. To be 100% honest, the distributed processing approach I proposed is just a thought experiment on how to decouple the many modules. Having each "module" on a different machine is usually how I think when I try to decouple complex stuff. I'll keep studying the code to try and figure out how it would be possible... 73 Rafael On Wed, Feb 28, 2024 at 1:01 PM William Smith via wsjt-devel <mailto:wsjt-devel@lists.sourceforge.net>> wrote: I get what you were trying to do, and it is not a perfect solution, but many people use VNC or some other kind of remote desktop protocol to remotely control the computer that is running WSJT. Yes, it would be much better to unload the GUI and the output video requirements from the poor Raspberry Pi and let that run on some machine that has a lot more available horsepower. However, as you are determining, that is a lot of work, and the remote desktop thing has the advantage of not requiring any coding at all from the WSJT team. 73, Willie N1JBJ > On Feb 28, 2024, at 7:11 AM, Rafael Pinto via wsjt-devel mailto:wsjt-devel@lists.sourceforge.net>> wrote: > > > Hello folks > > Sorry if this has already been discussed! > > I am Rafael, PU1OWL, and I was thinking if it would be possible to detach the GUI frontend from the modulation/audio/realtime backend of WSJT-X so we can make it a remote module > > The architecture I envision is having a remote processor (e.g., some bulky raspberry pi, a PicoITX i9 board...) dealing with the mathematical heavy lifting while not having to put CPU into presenting its GUI. The GUI could be remote, on a PC or another raspberry pi, or something even lighter... Or maybe even some audio sink board, forwarding to a hugely capable math processor, to a lightweight GUI... > > I started studying the source code, but I cannot find somewhere to split the code. Has it been tried before? > > 73 de PU1OWL > > Rafael Pinto > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel <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 <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
Re: [wsjt-devel] MSK144 in jt9.exe
Thank you, Joe! Much appreciated. 73 Alex VE3NEA On 2024-01-08 09:06, Joe Taylor via wsjt-devel wrote: Hi Alex, Thanks for providing additional details. I have merged your contribution into our 'develop' branch. The next release of WSJT-X will include MSK144 decode capability in the jt9[.exe] executable. -- 73, Joe, K1JT On 1/7/2024 10:58 AM, Alex, VE3NEA via wsjt-devel wrote: Hi Joe, Thank you for considering my submission. This change will allow jt9.exe to be used for decoding the MSK144 signals either from a wav file or from the shared memory. There were requests for such improvement in the past, see for example this posting: (https://sourceforge.net/p/wsjt/mailman/message/36905061/) I am working on an open source program that sits in the system tray and decodes the WSJT-X modes on multiple frequencies 24/7. This program uses jt9.exe for decoding, that is why I need these changes: it is better to use jt9.exe from the official distribution rather than a custom built command-line program. As I already mentioned, this does not affect the way MSK144 is decoded in WSJT-X and only adds a new option to jt9.exe for those who need it. 73 Alex VE3NEA On 2024-01-07 08:50, Joe Taylor via wsjt-devel wrote: Hi Alex, Thanks for your suggested changes to jt9.exe. As you know, decoding of MSK144 has always been done immediately as new data are acquired, rather than at the end of a timed receive sequence in the jt9[.exe] executable. Before we make any decision about merging your suggestions into the main branch of WSJT-X, could you elaborate just a bit about your intended purpose and any supposed advantages? -- 73, Joe, K1JT On 1/6/2024 8:12 AM, Alex, VE3NEA via wsjt-devel wrote: Hello team, I have made changes to the jt9.exe code to allow it decode MSK144. This does not affect the existing functions of WSJT-X, so it is a low risk change, and I would like it to be merged to the main branch. The modified files are attached. Do I need to do anything else to make my submission accepted? 73 Alex VE3NEA ___ 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 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 mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] MSK144 in jt9.exe
Hi Joe, Thank you for considering my submission. This change will allow jt9.exe to be used for decoding the MSK144 signals either from a wav file or from the shared memory. There were requests for such improvement in the past, see for example this posting: (https://sourceforge.net/p/wsjt/mailman/message/36905061/) I am working on an open source program that sits in the system tray and decodes the WSJT-X modes on multiple frequencies 24/7. This program uses jt9.exe for decoding, that is why I need these changes: it is better to use jt9.exe from the official distribution rather than a custom built command-line program. As I already mentioned, this does not affect the way MSK144 is decoded in WSJT-X and only adds a new option to jt9.exe for those who need it. 73 Alex VE3NEA On 2024-01-07 08:50, Joe Taylor via wsjt-devel wrote: Hi Alex, Thanks for your suggested changes to jt9.exe. As you know, decoding of MSK144 has always been done immediately as new data are acquired, rather than at the end of a timed receive sequence in the jt9[.exe] executable. Before we make any decision about merging your suggestions into the main branch of WSJT-X, could you elaborate just a bit about your intended purpose and any supposed advantages? -- 73, Joe, K1JT On 1/6/2024 8:12 AM, Alex, VE3NEA via wsjt-devel wrote: Hello team, I have made changes to the jt9.exe code to allow it decode MSK144. This does not affect the existing functions of WSJT-X, so it is a low risk change, and I would like it to be merged to the main branch. The modified files are attached. Do I need to do anything else to make my submission accepted? 73 Alex VE3NEA ___ 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 mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] MSK144 in jt9.exe
Hello team,
I have made changes to the jt9.exe code to allow it decode MSK144. This does not affect the existing functions of WSJT-X, so it
is a low risk change, and I would like it to be merged to the main branch. The modified files are attached. Do I need to do
anything else to make my submission accepted?
73 Alex VE3NEAsubroutine decode_msk144(audio_samples, params, data_dir)
include 'jt9com.f90'
! constants
integer, parameter :: SAMPLING_RATE = 12000
integer, parameter :: BLOCK_SIZE = 7168
integer, parameter :: STEP_SIZE = BLOCK_SIZE / 2
integer, parameter :: CALL_LENGTH = 12
! aguments
integer*2 audio_samples(NMAX)
type(params_block) :: params
character(len = 500) :: data_dir
! parameters of mskrtd
integer*2 :: buffer(BLOCK_SIZE)
real :: tsec
logical :: bshmsg = .false. ! enables shorthand messages
logical :: btrain = .false. ! turns on training in MSK144 mode
real*8 :: pcoeffs(5) = (/ 0.0, 0.0, 0.0, 0.0, 0.0 /); ! phase equalization
logical :: bswl = .false.
character(len = 80) :: line
character(len = CALL_LENGTH) :: mycall
character(len = CALL_LENGTH) :: hiscall
! local variables
integer :: sample_count
integer :: position
integer :: message_count = 0
! decode in 0.3s blocks
sample_count = params%ntr * SAMPLING_RATE
mycall = transfer(params%mycall, mycall)! string to char[]
hiscall = transfer(params%hiscall, hiscall)
do position = 1, sample_count - BLOCK_SIZE + 1, STEP_SIZE
buffer = audio_samples(position : position + BLOCK_SIZE - 1)
tsec = position / REAL(SAMPLING_RATE)
call mskrtd(buffer, params%nutc, tsec, params%ntol, params%nfqso,
params%ndepth, &
mycall, hiscall, bshmsg, btrain, pcoeffs, bswl, data_dir, line)
if (line(1:1) .ne. char(0)) then
line = line(1:index(line, char(0))-1)
write(*, 1001) line
1001 format(a80)
message_count = message_count + 1;
end if
end do
if (.not. params%ndiskdat) then
write(*, 1002) 0, message_count, 0
1002 format('', 2i4, i9)
end if
end subroutine decode_msk144program jt9
! Decoder for JT9. Can run stand-alone, reading data from *.wav files;
! or as the back end of wsjt-x, with data placed in a shared memory region.
use options
use prog_args
use, intrinsic :: iso_c_binding
use FFTW3
use timer_module, only: timer
use timer_impl, only: init_timer, fini_timer
use readwav
include 'jt9com.f90'
integer*2 id2a(18)
integer(C_INT) iret
type(wav_header) wav
real*4 s(NSMAX)
real*8 TRperiod
character c
character(len=500) optarg, infile
character wisfile*256
!### ndepth was defined as 60001. Why???
integer :: arglen,stat,offset,remain,mode=0,flow=200,fsplit=2700, &
fhigh=4000,nrxfreq=1500,ndepth=1,nexp_decode=0,nQSOProg=0
logical :: read_files = .true., tx9 = .false., display_help = .false., &
bLowSidelobes = .false., nexp_decode_set = .false., &
have_ntol = .false.
type (option) :: long_options(33) = [ &
option ('help', .false., 'h', 'Display this help message', ''), &
option ('shmem',.true.,'s','Use shared memory for sample data','KEY'), &
option ('tr-period', .true., 'p', 'Tx/Rx period, default SECONDS=60',&
'SECONDS'), &
option ('executable-path', .true., 'e', &
'Location of subordinate executables (KVASD) default PATH="."', &
'PATH'), &
option ('data-path', .true., 'a',&
'Location of writeable data files, default PATH="."', 'PATH'), &
option ('temp-path', .true., 't',&
'Temporary files path, default PATH="."', 'PATH'), &
option ('lowest', .true., 'L', &
'Lowest frequency decoded (JT65), default HERTZ=200', 'HERTZ'), &
option ('highest', .true., 'H', &
'Highest frequency decoded, default HERTZ=4007', 'HERTZ'), &
option ('split', .true., 'S',&
'Lowest JT9 frequency decoded, default HERTZ=2700', 'HERTZ'),&
option ('rx-frequency', .true., 'f', &
'Receive frequency offset, default HERTZ=1500', 'HERTZ'),&
option ('freq-tolerance', .true., 'F', &
'Receive frequency tolerance, default HERTZ=20', 'HERTZ'), &
option ('patience', .true., 'w', &
'FFTW3 planing patience (0-4), default PATIENCE=1', 'PATIENCE'), &
option ('fft-threads', .true., 'm', &
'Number of threads to
Re: [wsjt-devel] Omnirig 1.19 & WSJT-X 2.0.1 55 Hz artifact
Hello,
I emailed BillG4WJS yesterday and explained why this happens. I have not heard
from him yet, so here is a copy of my message.
73 Alex VE3NEA
Hi Bill,
I released OmniRig 1.19 about a month ago, this version solves a few problems that I faced when I started to use WSJT-X with my
new IC-7610 radio.
One problem was a slow T/R switching. WSJT-X sends multiple redundant commands to OmniRig that set the properties to the same
value that is already set. These commands have no effect, but they take time, especially if a CAT timeout occurs. I had
intermittent T/R delays of up to 2-3 seconds. I changed the code in OmniRig so that a CAT command is not sent to the radio if it
does not change the current value, and this dramatically improved the response time.
Another problem was the mode change, WSJT-X changed the mode of one VFO but not
of the other. This happened because of this code:
if (writable_params_ & OmniRig::PM_VFOEQUAL)
{
// nothing to do here because OmniRig will use VFO
// equalize to set the mode of the Tx VFO for us
}
This assumption does not hold for all radios. To solve this, I have added an option that sets the mode for both VFO's when the
Mode property is assigned a value. This option is controlled by a setting in the configuration file.
These changes solved the problems that I had with WSJT-X and my radio, but there is still a small glitch that was recently
reported by a user. The code that adds 55 Hz to the frequency reads the frequency back immediately instead of waiting for a
param change event, as a result it determines the resolution incorrectly, and with the new OmniRig it does not even undo the
frequency change because it tries to set the frequency to the same value that it already has.
Let us work together to fix the remaining problems, and perhaps simplify the WSJT-X code using the new features of OmniRig. You
can see my changes to the OmniRig code here:
https://github.com/VE3NEA/OmniRig/commits/master
73 Alex VE3NEA
On 2019-05-18 08:22, Black Michael via wsjt-devel wrote:
If it works in 1.16 and doesn't in 1.19 then it would seem to be OmniRig and
not WSJT-X. Alex must've broken it.
That frequency test has been in there for quite a while (a couple years perhaps?) and nobody else has this problem. It would
indicate OmniRig is dropping the frequency change request to return to the requested frequency.
de Mike W9MDB
On Saturday, May 18, 2019, 6:55:01 AM CDT, Mike wrote:
I am forwarding this conversation to amke sure you all know about this ...
I was running Omnirig 1.16 for years. I saw there was a new version (1.19) so installed it. Have two rigs in use in Omnirig:
FT-450D & IC-7300. Were no problems before with Omnirig or the communications to/from the radios.
Now with the new 1.19, suppose the FT-450D is turned on and it's freq. display reads 50.313.00. When I start WSJT-X using the
new Omnirig it changes the frequency to 50.313.05 on the radio display, and WSJT-X shows it's 50.313 055. If I use WSJT-X to
change bands the "55" Hz never shows up again no mater what band I go to. But shut it all down and start over, same thing
happens. 55 Hz is added to the freq, of the FT-450D.
On the IC-7300, same thing happens at first BUT - I can see the display briefly flash an extra 55 Hz on the display, then it
goes to the correct frequency in an instant most of the time. However, this morning it kept the extra 55 Hz on the display of
the IC-7300. Changing bands causes the 55 Hz to go away from then on (for that operating session) like the FT-450D.
If I go back to the .exe for Omnirig 1.16 - the problems all go away and all radios act perfectly fine just as they always did
for years. I did not change any settings when I switched to the new version to cause this. However; after I observed it happen
with 1.19 I tried to change various settings such as baud rate (also for the radios), time out and other items to no avail. In
any case it does NOT happen when I go back to Omnirig 1.16. Even with different settings. Omnirig 1.16 causes no problems at all.
I wrote the developer of Omnirig and got this response -
Hi Mike,
Thank you for reporting the problem. The frequency change by 55 Hz is not a
bug, WSJTX makes this change on startup to determine
the frequency change step of the radio. The program is supposed to undo the
change, but for some reason this does not happen. I
will contact the WSJTX developers to see how we can fix this.
Please note that I released OmniRig 1.19 in order to fix some serious problems
that WSJTX had with the old version. These
problems are now fixed, but the glitch you have reported still requires
correction.
73 Alex VE3NEA
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>
https://lists.source
Re: [wsjt-devel] FT8 CQ Fox block possible?
On 2018-05-09 10:40, Black Michael via wsjt-devel wrote: There apparently was somebody on 20M FT8 last night in Fox mode from a relatively rare location and caused a mess on 14.074. Everybody though he was calling simple CQ but was Fox so wasn't hearing them and users were crowding the lower end of 20M trying to get him making even the the Fox/Hound exchange problematic. I don't think we can leave this up to "operator responsibility" as there are just too many out there. I have seen quite a few semi-rare DX stations using the Fox mode recently. While I think they are doing a wrong thing, I can understand their temptation to increase their QSO rate by using the feature available in the software. Currently WSJT-X has two modes of operation, the standard mode (for non-DX stations) and the Fox mode (for rare DX). Maybe it is time to add a third mode, optimized for semi-rare DX. In this mode, there DX would transmit only one signal, anywhere in the standard FT8 segment, and the Hounds would not have to call above 1000 HZ and then jump below 1000 Hz to send the signal report, they would work the same way as in the standard mode. The difference from the standard mode would be only on the Fox side, the DX station would be allowed to send the DXpedition-style messages like "K9AN RR73; N7QT -05" to double their Q rate, and would have a queue function to make operation more convenient. I am sure that many semi-rare DX would use this mode instead of the Fox mode if it were available. What do you think? 73 Alex VE3NEA -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Audio input from RTP stream?
Hello developers, I am looking into supporting the RTP+RTCP protocol in CW Skimmer, and I want to do this in a way compatible with other software, including WSJTX. RTP seems to be the best way of exchanging the I/Q data between the programs, but it needs to be complemented with another protocol for reading and setting the radio's parameters. I was thinking about using NDJSON over TCP for that (https://github.com/ndjson/ndjson-spec), the solution that worked well in my GRITTY project (http://dxatlas.com/Gritty/). However, Hubert, HB9JND has drawn my attention to the new TCI protocol (https://github.com/maksimus1210/TCI) that seems to have all required radio control commands, but sends I/Q data via TCP. Do you think it would make sense to combine RTP+RTCP (for data) with TCI (for commands)? Would you be interested in supporting this combination in WSJTX? Are there any good alternatives to this solution? 73 Alex VE3NEA -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Callsign highlighting
Hi Bill, Your latest message aggregator works perfectly, both in the highlight-last and list-based modes. WSJTX now does all that I want, in terms of callsign highlighting. I used the new message to highlight the countries not worked this year, and improved my DX Marathon score significantly in just one evening. Thank you for your effort! 73 Alex VE3NEA On 2018-03-27 18:26, Bill Somerville wrote: On 27/03/2018 04:10, Alex, VE3NEA wrote: When I was initially experimenting with callsign highlighting, I painted all instances of the call that appeared after the last separator. I searched for "" backwards from the end of the text, then searched forward for the callsign, starting at that point. This proved to be unnecessary in the Highlight Last mode, but when this mode is off, you may want to use this method to ensure that highlighting does not propagate beyond the point of the band change. Of course, this will work only if separators are enabled. Hi Alex, thanks again fro the feedback. For the above I think that it is best left for the future when we have a much richer internal model of decodes, things like the dial frequency when they were decoded will eventually be stored alongside the decoded text, date, time etc. This will make this sort of logic far more practical. I suspect for the vast majority of users there is little care for decodes that have scrolled off the top unless they are for the last one or two T/R periods. I have added a bit more functionality to the message_aggregator reference application to exercise the highlight last instance only flag and to allow the selection of foreground and background colours in the "Calls of interest" list. This is only so I can test the message functionality fully, there are no WSJT-X implementation changes. Here's a new patch for any who might be interested: https://www.dropbox.com/s/7slm4oypbc5g8ks/highlight.diff?dl=0 I consider this patch a low risk and I am happy to merge it to the development branch even though we are already at RC3, which means it will make it into the v1.9.0 GA release. Unless you have any other suggestions on this functionality I will commit the changes tomorrow. 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 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Callsign highlighting
Thank you very much, Bill! You work very fast. I applied your patch, and the code worked perfectly. I am sure that there will be developers who will take full advantage of the callsign color list, and those who will use the Highlight Last mode to have more control. The reason why I want to highlight only the senders' calls is because one can double-click on them and start calling right away, while the stations whose calls are on the left side may not even be copyable, and double-clicking on them is not going to start a QSO with them. The Highlight Last option allows the server to specify the color for the left hand or the right hand call, or for both, and pass either the same or different colors. There is no need to add another option for that. When I was initially experimenting with callsign highlighting, I painted all instances of the call that appeared after the last separator. I searched for "" backwards from the end of the text, then searched forward for the callsign, starting at that point. This proved to be unnecessary in the Highlight Last mode, but when this mode is off, you may want to use this method to ensure that highlighting does not propagate beyond the point of the band change. Of course, this will work only if separators are enabled. 73 Alex VE3NEA On 2018-03-26 19:34, Bill Somerville wrote: Hi Alex, thanks for reviewing the changes. Some comments in line below. On 26/03/2018 18:23, Alex, VE3NEA wrote: 1. Some developers may prefer to highlight only the senders' callsigns, or at least use different colors depending on the callsign position in the message. Your code does not allow this. I'm not sure this is of great value as the callsign orders swap each period. I expect highlighting to be used either to indicate stations of higher value or worked before, either way it doesn't seem to matter which call position is being highlighted. I need more convincing on adding a position1/position2 specific highlighting capability. 2. The server may not be running when a call whose status has changed is decoded again, this results in incorrect highlighting. If there is no up to date info, it might be better not to highlight at all. The server does have the option to clear all the highlighting it has requested, of course this does rely on the server making a graceful exit. We must also be careful not to disrupt multiple servers, that might be highlighting different calls, although I don't see any immediate advantage to doing that, for sure the WSJT-X protocol does not disallow it if multicast group addresses are used. 3. When the status of a callsign changes, e.g. because we have worked it, the new colors are applied to all historical data, which is incorrect since the call was not a dupe until it was worked. I see your point although I'm not sure it matters much, working a station is an event in time but what's the harm in highlighting all instances of that call as un-needed once it has been captured. Having said that switching bands has a bearing here, maybe WSJT-X should forget all highlighting when switching bands, OTOH the server could do that itself too. All these issues could be fixed by adding an option to the highlight message that tells the client to apply the colors only to the last instance of the call and not to add an entry to the list. That is certainly quite easy to implement and it does add an extra capability. It would certainly facilitate a more dynamic approach which I think is your prime goal. The highlighting would still be cleared if a message with invalid colours were passed. I am a little concerned that only highlighting one instance of a callsign might confuse users, imagine a busy band where message scrolls away quickly, I assume you intend to have the server keep highlighting the callsign each time it is seen in a decode and therefore keeping the information current. Here is another patch: https://www.dropbox.com/s/7slm4oypbc5g8ks/highlight.diff?dl=0 I haven't updated the message_aggregator application to exercise the "last_only" callsign highlight option as I am out of time with an early start for work in the morning, but you have that option now. If you want to reverse out the previous patch then add a -R option to the previous patch command, or simply revert the files in svn. A reverse patch must be done with the original patch file so beware that I have used the same file name and overwritten the Dropbox file. 73 Bill G4WJS. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Callsign highlighting
Hi Bill, I applied your patch to WSJT-X and changed my UDP server to send two QColor parameters, everything works fine. However, there are a few issues due to storing the list of highlighted calls. 1. Some developers may prefer to highlight only the senders' callsigns, or at least use different colors depending on the callsign position in the message. Your code does not allow this. 2. The server may not be running when a call whose status has changed is decoded again, this results in incorrect highlighting. If there is no up to date info, it might be better not to highlight at all. 3. When the status of a callsign changes, e.g. because we have worked it, the new colors are applied to all historical data, which is incorrect since the call was not a dupe until it was worked. All these issues could be fixed by adding an option to the highlight message that tells the client to apply the colors only to the last instance of the call and not to add an entry to the list. 73 Alex VE3NEA -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Callsign highlighting
Hi Bill, The patch utility crashes when trying to apply this patch. Do I need to specify some extra command line switches? Maybe you could create a branch with your changes that I would check out instead? 73 Alex VE3NEA On 2018-03-25 18:52, Bill Somerville wrote: Hi Alex, I have added a few enhancements to your proposed patch: https://www.dropbox.com/s/7slm4oypbc5g8ks/highlight.diff?dl=0 this extends the UDP message to include the foreground colour as well as the background colour. The colours are passed as QColor format fields which are a little more complicated but are already supported by the Qt QDataStream formats. The main reason for the field format is that QColor can specify many more colours and also an invalid colour value (spec = 0). The invalid value is used to reset the background and or foreground colour to defaults. The internal implementation in WSJT-X keeps a dictionary of highlight commands send and applies the colours to all existing decodes and future decodes, this should explain the need for a resetting mechanism. As an example I have enhanced the WSJT-X MessageServer class and the reference message_aggregator application (the C++ Qt one) provided with WSJT-X to exercise the new UDP message, it does so by displaying a list of "calls of interest" which it relays to all connected WSJT-X clients. Callsigns may be added to, edited, and deleted (right-click the list for a context menu). Give it a try and see what you think. 73 Bill G4WJS. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Callsign highlighting
Hi Saku, Your logger knows a lot about the callsigns it displays. Once my changes are merged, cqrlog will be able to share some of this knowledge with WSJT-X so that the operator can see your colors directly in the Band Activity panel. You can use my TWsjtxListener class if you want, I hope it will compile in Lazarus without problems. I have added schema negotiation as Bill suggested, please re-download. 73 Alex VE3NEA On 2018-03-24 06:20, Saku wrote: Alex, VE3NEA kirjoitti 23.03.2018 klo 22:41: Hello, I have written some code that allows a UDP server, e.g., a logger, to tell WSJT-X what background color to use for each callsign in the Band Activity panel. This might be useful to those who chase various awards, if the logger assigns different colors to new IOTA groups, US counties, etc. The end result looks like on the attached screenshot. The .diff file is here: Hi ! Quite same what cqrlog does on it's own CQ-monitor. Colors of calls and locators vary (with up/lowcase ltrs) telling status compared to own log ( in Mysql database). It also warns (keep cool =blue) about directed CQ if own continent compared to caller continent is same (I'm no DX) or if directed call is not directed to own continent. Cq's can be answered by double click of corresponding line. "Follow" property's line can also be double clicked and it uses 1.9.0.rc3 new feature that loads Std messages, but does not fire TX. -- Saku OH1KH -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Callsign highlighting
Hi Bill, Thank you for a link to your message aggregator. I will take a closer look at it tonight, it looks like it includes a useful piece of code for working with the wsjt-x messages. I included the Delphi project only as a testing tool for the new feature in wsjt-x, so please ignore it if it is incomplete. My C++ code does not change the caret position, the callsign is highlighted using a temporary cursor object. 73 Alex VE3NEA On 2018-03-23 17:14, Bill Somerville wrote: On 23/03/2018 20:41, Alex, VE3NEA wrote: I have written some code that allows a UDP server, e.g., a logger, to tell WSJT-X what background color to use for each callsign in the Band Activity panel. This might be useful to those who chase various awards, if the logger assigns different colors to new IOTA groups, US counties, etc. The end result looks like on the attached screenshot. The .diff file is here: http://www.dxatlas.com/Misc/callsign_highlight.zip The zip also includes a Delphi class for listening and replying to the WSJT-X messages, and a demo program that shows how to use the class, which is also useful for testing the new feature once it is included in WSJT-X. Please review and merge if OK. Hi Alex, looks good but I have some issues. Please check out this: https://www.dropbox.com/s/xlvc5kxy85ymtn9/message_aggregator.zip?dl=0 , it is a very basic UDP message server application written in Object Pascal and also uses Indy for services. The message cracking routines may be useful to you, free free to copy them - all I require is credit. I will look in more detail at your patch, I have a concern about cursor positioning in the decode windows that I need to check. There is a requirement to negotiate the message schema number if you intend to send messages back to WSJT-X instances, this is necessary in case a new schema is introduced as the WSJT-X UDP messages are a grid topology and all nodes must agree on the "on the wire" message schema. The schema number is allowed to decrease if an old lower schema node joins the party. The MessageServer.cpp class in the WSJT-X sources does this correctly. See code at line 155 handling Heartbeat messages here: https://sourceforge.net/p/wsjt/wsjt/HEAD/tree/branches/wsjtx/MessageServer.cpp . I also have a partial implementation of joining a multicast group for the AutoIt scripting language, this is relevant because it has no built in library support for multicast and it is used to implement the current version of JTAlert, so JTAlert must bind a unicast address for now. If JTAlert is in the grid then it must degrade to a single server (JTAlert) many client (WSJT-X) topology, which excludes other servers :( I need to find time to complete this and offer it to Laurie as a plug in replacement for the AutoIt UDP server module. 73 Bill G4WJS. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Callsign highlighting
Hello, I have written some code that allows a UDP server, e.g., a logger, to tell WSJT-X what background color to use for each callsign in the Band Activity panel. This might be useful to those who chase various awards, if the logger assigns different colors to new IOTA groups, US counties, etc. The end result looks like on the attached screenshot. The .diff file is here: http://www.dxatlas.com/Misc/callsign_highlight.zip The zip also includes a Delphi class for listening and replying to the WSJT-X messages, and a demo program that shows how to use the class, which is also useful for testing the new feature once it is included in WSJT-X. Please review and merge if OK. 73 Alex VE3NEA -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] DXpedition Mode Test Results
- Of course, some Hounds did not operate as intended. Several kept trying to raise Fox by calling below 1000 Hz. Perhaps the software should block attempts to send Tx1 below 1000 Hz if Hound mode is enabled, and show a popup message explaining why transmission did not start. 73 Alex VE3NEA -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] DXpedition mode test results
There was no propagation on 20m and 30m, but on 40m and 80m I worked DX quickly and without problems. There were a few glitches that are hopefully not difficult to fix. 1. When the Fox answered my call at 01:02:00 (see the attached screenshot), his message appeared on the left panel but not on the right one. 2. Two or three blank messages were received during the test. 3. Repeated RR73 have already been reported, but here is an interesting case: two RR73's were sent to me in the same time slot, on 313 Hz and 433 Hz (visible on the same screenshot): 010300 -13 -0.7 313 ~ VE3NEA RR73; N4EFS -10 010300 -12 -0.7 372 ~ AB3CV RR73; W5TKZ -10 010300 -13 -0.7 433 ~ VE3NEA RR73; K4SO -05 010300 -14 -0.7 493 ~ AB3CV RR73; K1WSN -09 My apologies if this is a feature rather than a bug. After all, the second VE3NEA RR73; has zero cost because the same message starts another QSO, so it makes sense to include it and improve the chances of RR73 being copied. 4. Probably not a glitch, just an observation: sometimes the Fox has more QSO in progress than it has slots. Below, the Fox answers my call at 02:07:00, then at 02:07:30 it does not RR my report but finishes three other QSO (and starts three new ones), and only at 02:08:00 sends RR73 to me: 180307_020645 Transmitting 3.585 MHz FT8: K9AN VE3NEA FN03 020700 -6 0.1 304 ~ W9EQ RR73; VE3NEA -06 020700 -4 0.1 364 ~ AF3I RR73; KC4JNW -05 020700 -3 0.1 424 ~ W3RJW RR73; WA4MIT -05 180307_020715 Transmitting 3.585 MHz FT8: K9AN VE3NEA R+04 020730 -4 0.1 304 ~ VE2EBK RR73; KF0QR -05 020730 -1 0.1 364 ~ W9EQ RR73; W8BAR -05 020730 0 0.1 424 ~ AF3I RR73; K4DSP -04 180307_020745 Transmitting 3.585 MHz FT8: K9AN VE3NEA R+04 020800 -2 0.1 304 ~ KC4JNW RR73; WW8RT -04 020800 0 0.1 364 ~ W7AH RR73; KG4W -04 020800 0 0.1 424 ~ VE3NEA RR73; N2ADV -04 It is not clear if this behavior increases or decreases the QSO rate. 73 Alex VE3NEA -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Fwd: Type 2 prefix validation
WSJTx could suppress invalid messages like this: 203500 -19 0.1 513 ~ CQ 02E4/XX4IWT JO12 !where? by performing a simple validation of type 2 prefixes. A valid prefix has one of these patterns: @ @@ @@# @@#@ @# @#@ @## #@ #@@ #@# #@@# where @ is any letter and # is any digit, and the first character cannot be a 0 or Q. 73 Alex VE3NEA -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Fwd: Re: 20 M FT8 freqs for DXpeditions? (long)
Of course, 400W should be the average power of the amplifier, not the peak power. Splitting the power unevenly between the messages (in favor of the callers on a difficult path) may improve the peak to average power ratio. 73 Alex VE3NEA On 2017-08-20 16:15, Joe Taylor wrote: Hi Rich, Ned, Alex, and all, On 8/20/2017 2:15 PM, Alex, VE3NEA wrote: Hi Ned, Your picture of the future FT8 pileups of the top-ten DXpeditions is very realistic but very scary. ... ... A 400 W linear amplifier will easily transmit 10 x 40W signals if it is linear enough. Surely this is wrong. If everything is linear, instantaneous voltage (not power) is additive. If a single constant-envelope signal has (voltage) amplitude V and power P at some point in the transmitter, the addition of 10 similar signals carrying different messages can (at some instants) be as high as 10V. The peak envelope power will then be 100P. The transmitted waveform would no longer have anything like a constant envelope. Your 400 W linear would be OK for 10 x 4 W signals, but not for 10 x 40 W. A rate of 1000 QSO per hour, or more, may be possible, which will beat all other Ham modes. A scary idea, indeed! -- 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 -- 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] Fwd: Re: 20 M FT8 freqs for DXpeditions? (long)
Hi Ned, Your picture of the future FT8 pileups of the top-ten DXpeditions is very realistic but very scary. As a DX'er, I realize that none of the usual pileup cracking techniques that I use in CW and RTTY are going to work in this scenario, and I will have very little control over the things. All I will be able to do to improve my chances of a QSO is monitor my TX frequency and QSY when necessary to stay in the clear. This is the nature of FT8: one cannot pick the right time for sending his call since the time intervals are fixed, and one cannot pick the right frequency because all frequencies are decoded simultaneously. Perhaps multiple 2-kHz slots will add an extra dimension to the picture and allow the DX'ers to do something intelligent. On the bright side, the FT8 mode is not only capable of multi-channel reception, but, with proper modification of the software, it could do multiple transmissions as well. It is possible to send, say, 10 messages within the 2-kHz slot at the same time, and improve the QSO rate by a factor of 10. A 400 W linear amplifier will easily transmit 10 x 40W signals if it is linear enough. A rate of 1000 QSO per hour, or more, may be possible, which will beat all other Ham modes. 73 Alex VE3NEA P.S. Thank you for the RTTY QSO with VP8STI and VP8SGI! I tried different techniques in these pileups, but tail-ending was the only one that really worked. I used the waterfall display of CW Skimmer to track your tuning pattern, perhaps that's why I succeeded with my modest station setup. On 2017-08-20 12:25, Ned wrote: Rich, I would like to add some perspective of what might happen when what is called a "Top Ten" DXpedition (a DXCC entity that is in the Top Ten slots in published need lists...examples being Bouvet and Baker Island that will be QRV early next year) takes place on RTTY (or any digitial) mode. Having been the "RTTY guy" on both VP8STI and VP8SGI last year (both on the Top Ten at that time), the pileups are hard to describe. RTTY operation on these two DXpeditions was confined to 2 bands, basically, in order to prevent issues that arise in the use of Clublog Leaderboard. So the DXpedition leadership opted to limit RTTY to two bands (30 and 15 meters) in order to maximize the number of ATNOs (All Time New Ones) on the digital modes. As a result, the pileups were huge and stayed huge until we left both islands. When I called CQ the very first day on South Sandwich Island (VP8STI), the pileup was 30 KHz wide and hundreds deep. I have been in many RTTY contests and other DXpeditions (27 so far), but I had never experienced anything like this before. Using MTTY from within N1MM, the logging application for the DXPedition, it was virtually impossible at times to find complete calls in the pile. Over half of the time, I had to work QSOs in the same manner as one does on CW where I would type in a partial call and fix it when the station would send their report. There seemed to be few chances for me to use a mouse to pick a call out of an area on the computer screen. My hands were literally glued to the keyboard to make QSOs at a high rate. I manually spread the pile by trying to randomly pick calls across the breadth of the pile to prevent "tailending". I could never pick out one call in a tailend pile. So, while I was sending my QSL/QRZ message, I literally spun the dial of the receiver either up or down to a new frequency to work the next station. After doing this a while, everyone in the pile stopped trying to tail end and the rates settled into the best that could be done. FT8 is perfect for doing this, BTW. The only real tool in the hands of the DXpedition operator is to spread the pile until calls could be copied and making it easy for the DXpedition team operator to briskly sweep the spreadout pile to find calls. What Rich is suggesting below is spot on. FT8 operation at a Top Ten DXpedition might only be possible if the operator can make QSOs at a good rate, otherwise they will go back to RTTY. Rate is king. My fear is that the piles might get so deep that the decoders produce nothing and the rate goes to zero. Bad things happen when the rates go to zero on DXpeditions. Blistering emails and jamming are a few of the normal byproducts when confidence in the DXpedition team is lost. I am of the opinion that a Top Ten DXpedition will need more than one 2KHz slot to thin down piles at times...maybe all the time. Here are a couple of suggestions...I am a frequent user of FT8 and have been using JT65 on EME DXpeditions for years, so these are hopefully framed correctly... 1. Create a DXpedition mode in FT8 (similar to Contest Mode) where the appropriate information is used in an exchange. I don't think grid squares are needed. Signal reports are dubious in my mind. Some are saying that signal report info might be useful in analyzing propagation. My experience with FT8 so far is that the repor
Re: [wsjt-devel] DXpeditions - FT8, Split or not to split
good point about needing handy use of function keys for controlling progress of a QSO. DXped ops "never use a mouse", etc., etc. With a multi-decoding system like FT8 likely producing decodes from 30 or more eager callers, how are we to choose one of them with function keys? A DX operator absolutely needs to keep his hands on the keyboard when working CW or SSB because he has to type the callsigns in. When working in the digital modes, some may prefer to do the opposite, that is, to use only the mouse and avoid the keyboard as much as possible. This operating style is quite popular among the RTTY contesters who just left-mouse-click on a callsign to answer the call, and right-click to finish and log the QSO. Here is a discussion on the RTTY Contesting list about keyboard vs. mouse: http://lists.contesting.com/_rtty/2011-02/msg00389.html If possible, FT8 software should allow mouse-only operation, many users will appreciate it. 73 Alex VE3NEA -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT on DXpedition
Hi Joe,
The HF pileup QSO sequence that you suggested in your email is perfect for the normal case, when both parties copy each other
without problems, but some edge cases need to be discussed in more detail. The communication channel can fail at any stage
during the QSO, in one direction or another, and the QSO sequence must handle all such cases reasonably. Here is one case of
concern:
{
Note that VK9MA does not proceed to the next caller until receiving "RRR" and
logging the QSO. In the first sequence of example
QSOs, if Tx#4 is not received then #5 should instead be a repeat of #3. This message
should continue to be sent until the "RRR"
is received (or the VK9MA op gives up and calls someone else).
}
According to your description, the sequence is going to be like this:
1. CQ UP VK9MA QH72
2.VK9MA K1ABC FN42 | VK9MA W9XYZ -13
3. K1ABC VK9MA R QH72
4. VK9MA K1ABC RRR
5. K1ABC VK9MA R QH72
6. VK9MA K1ABC RRR
7. K1ABC VK9MA R QH72
8. VK9MA K1ABC RRR
9. W9XYZ VK9MA R QH72
How does K1ABC know if VK9MA logged the QSO with her or not? According to your description of the QSO sequence, VK9MA sends
message 9 in both cases. Should K1ABC log her contact or make another attempt? Those who are not active HF DX chasers cannot
imagine how much frustration such uncertainty will cause if not resolved properly. Please provide a way to make it clear if the
QSO was logged or not. We need some equivalent of the CW messages "TU UP" and "NIL UP". Can you suggest the best way of doing this?
This is not the only way how a QSO may end in an ambiguous state. One good way of making sure that all situations are handled
properly is to list all possible stages of the QSO and all possible messages (perhaps using a C++ Enum declaration), and develop
a table that defines what should be done in each stage if the given message is received, or if nothing is received. Two tables
will be needed, for the DX and for the caller. Such tables will be a good basis for the state machine that implements the QSO
sequence.
73 Alex VE3NEA
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Short QSO scenario
The JT65 Communications Protocol document describes two QSO scenarios, an HF-type scenario that consists of 4 messages, and a VHF-type one, that consists of 6 messages. Currently the FT8 Auto Seq function in WSJT-X supports only the VHF scenario. Since FT8 has become so popular on HF, the HF-style auto sequence should probably be implemented as well. The message sequence would be like this: 1: VK0EK VE3NEA FN03 2: VE3NEA VK0EK -20 3: VK0EK VE3NEA R-15 4: VE3NEA VK0EK RR CQ Note the last message that both completes the current QSO and invites other stations to call. This message should be added to the already existing list of special messages (CQ, QRZ and DE). I hope there is still a spare grid square around the North Pole for this new message. The first three messages in this sequence work the same way as in the 6-message scenario. At stage 4, if the caller (VE3NEA) receives (4), he knows that the QSO is complete. If he receives (2) again, this means that the DX did not copy his report, so he repeats his message (3). If he receives "CQ VK0EK MD66" instead, the caller knows that the DX OP has given up, and the QSO should not be logged. If nothing is received at stage 4, then perhaps (3) should be sent a couple more times before giving up. Would it be possible to implement this scenario as a user-selected option in Auto Seq in WSJT-X? 73 Alex VE3NEA -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Devel Build 7934 - Problems decoding
I am trying WSJT-X r7934 using FT8, calling DX stations with Auto Seq enabled. I have noticed that the program keeps sending my call even after DX has answered another station, as in the transcript below: 030130 -14 0.9 1909 ~ CQ CP6CL FH82 !Bolivia 030146 Tx 1909 ~ CP6CL VE3NEA FN03 030200 -14 0.9 1910 ~ CQ CP6CL FH820 1 030215 Tx 1909 ~ CP6CL VE3NEA FN03 030230 -14 1.4 1909 ~ CQ CP6CL FH820 1 030245 Tx 1909 ~ CP6CL VE3NEA FN03 030300 -15 1.3 1908 ~ UA1ZFG CP6CL -10bsp; 0 1 030315 Tx 1909 ~ CP6CL VE3NEA FN03 Is this the intended behavior or something that needs to be fixed? 73 Alex VE3NEA -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
