On Fri, Jan 17, 2020 at 8:21 AM Frank Kirschner <kirsc...@erols.com> wrote:
> All I suggested was that improving the software discriminator in a RTTY > program might produce a useful improvement in noise performance. > Frank, in my opinion you are lobbying the wrong developers here. If there are ideas in WSJT-X that could significantly improve 170 Hz 45.45 RTTY decoding, it's the RTTY decoder developers who are in the best position to implement them. WSJT-X code is GPL'd; point the RTTY folks to the relevant parts and tell them to have at it. > And if somebody wrote such a program, it would be useful to integrate it > to some extent with WSJT-X to make switching modes easier. > Now that just seems wrong-headed. There is nothing in WSJT-X that recommends itself as a framework for a conversational mode like RTTY. 73, Paul K6PO On Fri, Jan 17, 2020 at 8:21 AM Frank Kirschner <kirsc...@erols.com> wrote: > > > On Wed, Jan 15, 2020 at 1:44 PM David Gilbert <xda...@cis-broadband.com> > wrote: > >> >> You're assuming that the algorithms used in WSJT-X would be adaptable to >> RTTY to give better performance than what is already out there. >> > > It is certainly true that the algorithms used in WSLT-X for discriminating > frequencies could be adapted for RTTY. Why wouldn't they? All they do is > discriminate what frequency is being received. I'm not sure that the newest > RTTY programs don't already use this same algorithm, but the noise > performance of the RTTY programs I've tried so far has been pretty poor, > and improving the algorithm used would ameliorate that. > > I don't think there is any evidence of that being the case, given the >> very rigid constraints that every single WSJT-X mode requires. >> > > That has nothing to do with it. At some point in the flow of the both RTTY > programs and WSJT-X, a decision is made: was it this frequency or that > frequency? There's an algorithm that does this. I suspect that the writers > of WSJT-X have used the best algorithm that would run on computers > available, This algorithm, used in a RTTY program, would improve the noise > performance of decoding. The integration time available for RTTY is much > less than modes like FT8, and FT8 uses redundancies and limited code words, > but they both need to discriminate between frequencies. The work that > WSJT-X does over and above frequency discriminating has nothing to do with > RTTY, and it wouldn't be in a RTTY program. > > >> The appeal of RTTY for almost everyone (compared to FT8 or FT4) is its >> free form nature. Just go read the current dialog on the CQ-Contesting >> reflector to see what I mean. >> > > PSK-31 is much better for free-form communications than RTTY. It has > better noise performance and can copy through fades better. I believe most > people who operate in RTTY contests don't use a free-form mode anyway. They > have the exchange in macros, including the QSO counter, and they never > touch the keyboard. If there are many stations on, retyping the same info > for every QSO would be a waste of valuable operating time. All the RTTY > programs I've tried have macros and some sort of contesting mode. > > >> If you try to turn RTTY into a 2-tone version of FT8 neither user base >> will ever use it because it doesn't have the advantages of either mode. >> > > I don't know why people keep saying that. I never suggested a change to > RTTY. All I suggested was that improving the software discriminator in a > RTTY program might produce a useful improvement in noise performance. And > if somebody wrote such a program, it would be useful to integrate it to > some extent with WSJT-X to make switching modes easier. > >> >> Secondly, WSJT-X is simply a very bad contest user interface. It was >> designed for weak signal DXing and it does a very good job for that, but it >> is terrible for contesting. Again, check out the CW-Contesting reflector >> (you can just read the archives if you aren't subscribed) to see more >> comments on that point ... most of which have been from me. >> > > No one suggested using the WSJT-X UI for a RTTY program. The discriminator > and the UI are independent of one another. Someone could create a program > with the same discriminator algorithm that WSJT-X uses, and give it a very > contest-ready UI. The pace of FT8 contesting is much slower than that of CW > or RTTY. It's very leisurely, and optimizing the UI for contesting isn't > necessary. WSJT-X does have a number of user conveniences, like automatic > logging, so clearly some thought has been put into making it a practical > program, as opposed to just a test program for a lab. > >> >> I really don't think you understand what you keep proposing here, >> > > I assure you, I do. I have the academic and teaching credentials that show > I do. But that's not the issue here. > > I suspect you don't understand what I'm proposing, based on your comment > above. I'm not proposing a change to RTTY, as you suggested, but an > improvement in an algorithm in RTTY receiving programs. > > Let me restate in clearer terms: It would be nice if someone (not > necessarily the WSJT-X developers - there are other programmers in the > world, so it wouldn't take time away from the WSJT development) wrote a > RTTY program that played well with WSJT-X, SliceMaster, and JTAlert, and > used the best frequency discrimination algorithm currently available. That > would facilitate switching modes, provide very useful "needed" and "B4" > alerts, and improve noise performance over current RTTY programs. Since FT8 > and RTTY are often used in the same contests, switching back and forth > easily would be useful feature. I'm NOT proposing any changes to RTTY. > > but it doesn't really matter because there is no way Joe Taylor is going >> to mess with it since I'm sure he does. >> > > Joe Taylor is a very good scientist and programmer, but he's not the only > programmer in the world. Other people might be interested in this. > > There is rumored to be a new version of CW Skimmer in the works, one that > will integrate well with Flex Radio's SSDR. It will be callable by > SliceMaster, the same program that calls WSJT-X on many hams' set-ups. So > other people can still provide the ham community with useful software. > Clean integration of programs is becoming a more significant goal as more > and more functions are computerized. I don't see why this shouldn't be the > case with RTTY. > >> >> Dave AB7E >> >> 73, > Frank > KF6E > _______________________________________________ > 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
