Hi Tony, Thanks for following up. We’ve tweaked the Fast decode setting for the next release. It should work much better on your RigPi.
73 Steve k9an > On Jun 14, 2020, at 10:24 PM, Tony <[email protected]> wrote: > > Hi Steve – > > Sorry it has taken a few days to answer your questions, and think I have now > figured out how to edit e-mails and the subject line when responding on this > forum … not new to WSJT-X, but new to formatting responses on this forum. > > As a reminder, this is on a RigPi (3B+) connected via USB to a FT-991 working > FT-8. On the RigPi, my typical DT values for transmissions that I think have > well set clocks are 0.0 to 0.3. I see this using 2.1.2 and 2.2.1. This > seems pretty steady for lots of decodes on a busy band or light bands. > > On 2.2.1, I see just a very few decodes in the first decode pass of the > cycle, a quick flash on the decode button on the second (which makes sense > from what was described in this thread as happening in that cycle) and then > very many in a long, third pass that runs well into the next cycle. All of > this is seen in the FAST decode mode on 2.2.1. On 2.1.2, in the FAST decode > setting, I get many decodes which are complete by a second or two into the > next cycle. > > I did go back and look at the RigPi behavior on 2.1.2 on NORMAL and DEEP. > The RigPi does take a fair amount of time to decode a busy band into the next > cycle for those settings, but as mentioned, it works just fine using FAST. > So I understand the compute resource issue with the RigPi, and know it is not > as good a device for NORMAL or DEEP as then FT8 bands have become more > crowded. What I don’t understand is why with FAST the 2.2.1 decoder has > slowed so much. > > I have also set-up 2.2.1 on a Mac-Mini … older, but a lot more robust than a > RigPi. That system decodes in FAST, NORMAL, and DEEP with a performance I > would expect (2.4 Ghz Intel, cached HD). As you probably already know, the > RigPi is something like a 1.4Ghz ARM. > > So I know a hardware upgrade will fix my issue, but still wondering what > happened to FAST decode that used to work on the RigPi. > > ’73 - Tony > > ---- Prior message in thread --- > > Message: 2 > Date: Tue, 9 Jun 2020 08:39:08 -0500 > From: Steven Franke <[email protected]> > To: WSJT software development <[email protected]> > Subject: Re: [wsjt-devel] wsjt-devel Digest, Vol 76, Issue 93 > Message-ID: <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > Hi Tony, > > > Using a 2.2.x version, decoding on a busy band has the following behavior: > > first decode in cycle picks up a few messages, second decode a few, then > > the third decode runs a long time (well into the next cycle) and the > > majority of messages get decoded on that third decode. > > What are your typical DT values, i.e. what is the median DT value for a cycle > that has a good number of decodes? Normally, we expect to see the bulk of > the decodes produced by the first decoding segment (say, 80%) and only a > small number of decodes produced during the third segment. However, if there > is significant receiver latency, this can push most of the decodes into the > third segment. > > FWIW, no decoding is done during the second decode segment. This segment is > used to subtract all of the decodes that were obtained during the first > segment. > > Steve k9an > > > > _______________________________________________ > wsjt-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
