I sent this to the wsjt-devel-requests list but it looks like it was bounded
back, so I'm re-sending to this group. Sorry if it becomes a duplicate...
Hi All - I've been running WSJT-X 1.7.0-devel r6774 for several weeks now on a
Raspberry Pi 3 (RPi) with the Raspian Jessie OS. I know, this is most certainly
not the fastest processor in the world for doing decodes. But, it does work and
I've made quite a few successful QSOs (JT65 and JT9) with it. Firstly, let me
say that I think this is excellent software and it has been a pleasure to have
it available. Further, the help I got from Bill Somerville getting it and
Hamlib compiled on the RPi was extraordinary.
OK, so - my request is related to the sequence of decoded signals. Some
background: Not being familiar with the code, I can only presume from what I
see on the display. It appears that the JT9 decodes go out first, followed by
the JT65 decodes. Within each of those two "sub groups", the decodes are in
frequency order, such that the lowest ones display first. On a "normal" fast
processor, this is not a problem, nor is it an issue on a band with only a few
stations to be decoded. However, on 20 meters, especially on a weekend, the
poor little RPi doesn't complete it's decode displays until the :00 mark has
passed. Further, if the band is really hopping, I've seen it take until the :10
mark to complete.
And why is this a problem? Let us say I answer the CQ of a JT65 station who is
parked at about 2400 on the spectrum. The program goes back to RX mode and I
sit there while a bazillion of other signals are streaming down the spectrum
display, many down below that 2400 mark, along with a handful of JT9 guys up
higher. Then the decodes begin. Often, by the time it gets to displaying the
signals up near the 2400 mark, we've passed the :00 time and usually are into
the :04 to :07 area. By then the RPi has started transmitting his signal
report, and I notice that he had answered someone else, so I've quickly got to
terminate my transmission. Ugh..... What I've been doing is to disable the
Enable TX button until I see who he's answered. Kind of a PITA to have to do
this every time. My other option is to only answer station's CQs in the bottom
part of the band segment, so I will see their responses first, and that is a
larger PITA. Yeah, I know - that's life when using an RPi. But I'm sure I am
not alone in the use of small, low power computers for doing this weak signal
work. Not everyone has an eight core super-whammo computer to use for WSJT-X
operating.
Now, what is my suggestion? How about if during the decode pass, that a signal
decoded within +- a few Hertz of the operator's current receive frequency is
the FIRST thing sent out to the decode display window? That would give the
operator of the RPi (or any other "slow" processor) enough time to decide if
his next transmission should be aborted or proceed as normal. If the "decode
code" would look to see if (1) the Enable TX is turned on, and (2) there is a
signal very close to the receive frequency, dump it out to the display first.
Now THAT would be cool... :-)
Anyway, thanks for at least reading this and thinking about it.
73, Jim / W6JHB
------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
