Why isn't there a dedicated RTTY mode?

Chris DL5NAM

Keith, it's a good idea.
But only after we have all this basic modes that EVERY radio has. Also the real cheap radios have. And if these basic Modes are include then SSDR will be for me the version 1.0. Still we have Beta version 0.1.38 ;-)

Jay -- N0FB

With the addition of the Wave Form API which will be released sometime after 1.4 (1.5?), the open architecture will allow for Flex Radio Systems AND 3rd party developers to more easily develop and insert almost any mode into the 6000 family including FSK.  I think what you are hoping for will become available in the not too distant future.

Peter K1PGV

You know, I think this is really an interesting problem.

I came to ham radio later in life than most folks.  I've only been doing this for about 7 years.  So, when I started, digital modes had already been well established and I've always seen RTTY as "just another digital mode, like PSK-31, MFSK, or whatever."

So, whenever I worked RTTY, I would do so with a really wide set of tx and rx filters (like 5K wide each), and select where on my waterfall to work via my digimode program.  I would click on an RTTY signal, and my digimode program would center the AFSK frequency on it... when I spotted somebody, it would spot the center of the frequency.

I never even KNEW there was any other way.  It took me a long time to realize (a) different people work digital modes in very different ways, and (2) RTTY is special in a historical context.

So, there seems to be a bit of a split between the people who think "RTTY is just another digital mode, handle whatever you need done in the digi-mode program" and those who think "RTTY is unique, and we should be able to use an older-style "standard" RTTY program and have special support for an RTTY mode in the radio.

It quite literally took me years to understand this argument. And there's obviously no absolutely "right" or "wrong."

But it seems pretty clear to me that if a group of ops want to operate a certain way, expect to operate that way because that's the way that's supported by "standard" or "traditional" mode-specific programs that they know and love, and other radios indeed operate that way... then I can't see any way that SSDR can avoid eventually supporting this way of operating.

It won't be an style of operating I use, but I see how it could be really important to some folks.

Peter
K1PGV

Keith Regli (K7KAR)

Hey Peter,

I remember you from hanging out on Kathy Nearing's deck 20 years ago.  Don't think we talked about radio then.

I'm just figuring out how to use the 6500 I got in December, but I've been doing RTTY for about 50 years.  I think there are only a couple of things needed to make a real RTTY mode in SSDR, then there are some "nice to haves" and finally some things that people may want, but I think would be a mistake to add to SSDR.

The ability to click on a trace in the waterfall and have the intended signal centered in the appropriate filter is probably the main issue.  This also applies to logging programs which use band maps and/or packet spots to tell the radio the frequency of a desired signal.  Right now if you use DIGL which has a default filter center of 1500 hz and set your decoding program (usually something like 2-Tone) for Mark=1425 and Space=1585, the filter setup is easy, but you're off by 1500 hz.  For contesting and DXing this can be a big pain.  This is less critical for casual operating which should be more like other digital modes.

It would be nice to have a RTTY filter that was about 350 hz wide with a notch in the center (kind of a comb filter).  With the modern decoders I'm not sure that's too important anymore.

Some folks might like a RTTY decoder and maybe message buffers (ala CWX), but I think that would be a mistake.  FRS only has so many programming resources and there are others out there working on logging and decoding programs (N1MM, Writelog, MIXW tied to 2-Tone and MMTTY).

On transmit, it's pretty easy and reliable to setup AFSK through DAX, but historically, FSK has been a little more reliable and could avoid the offset problem.  Until I got the 6500 I've always used FSK, but using the DAX interface has made me feel very confident with the AFSK model.  For practical purposes FSK and AFSK produce the same results in a well designed radio.

Historically, the tone frequency for mark was 2125 hz because an 88mh torroid and a .068uf capacitor made a nice filter.  We've moved on from that, so holding to the old standard frequecies is pretty much irrelevant.  Today, shift is mostly 170 hz, but could be different.  Again, that should be controlled in the decoder and just allow filters to be wider or narrower.

I'm rambling, but maybe it will help non-RTTY people understand the desire for a RTTY mode.  Personally, I really like the 6500 and don't see it as a big problem.

David Decoons, wo2x

I agree with what you are saying and here's a few suggestions on what I would like to see.

A dual peak filter for RTTY, similar to how the Kenwood TS-990 does it. The 990 internal decoder is one of the best RTTY decoders I've used, especially when engaging the peak filter.

True FSK keying would be a good thing to ensure best IMD. If the AFSK levels are not set correctly along the digital audio chain, it can impact the TX IMD. FSK would eliminate the possibility of a tx level issue.

User configurable mode specific filters. Similar to what we had with PowerSDR. The ability to create custom rx filters that are a single mouse click away.

Dave, wo2x

ctate243

Having a couple rtty plaques on the wall I totally and fully agree from my fellow contester from 8P. action on this front could get folks from using the 6000 black boxes instead of the other black boxes most contester default to now because they have these bases covered.

 De N6WM

Mike

Dedicated or not, SSDR cannot be set up to operate RTTY correctly. On my low end radio, an FT-857D, the frequency display can be offset to display the RTTY Mark frequency. This is the generally recognized way an RTTY frequency is displayed on most radios, spotting nets etc. SSDR, however, displays the carrier frequency. Unlike SSB, the carrier frequency does not have any relation to the actual transmitted frequencies anywhere except in my radio. Why is this a problem? Suppose I work a station on 3599 kHz. SSDR sends to my logging program 3600.585 kHz (assuming the standard  SSDR 1500 Hz digital filter offset). I just logged an RTTY QSO out of band! I didn't make it out of band -- just logged it that way. If I spot the QSO, it spots it out of band which, in the heat of the contest, may send other stations out of band. I hope the contest sponsors for the CQ WW WPX RTTY don't check for out of band operation. A few of my QSOs were logged that way. --Mike, WV2ZOW

ctate243

Yes Mike...  This is definitely a hot button item I think probably needs high level flex attention.  I have been struggling with this as well..

Flex radio team please provide a solution as this should be core functionality.  Remoting wont be any fun if we are always off qrg ;-)

~Chris, N6WM

Chris DL5NAM

Hello FRS can you hear us ?!

DrTeeth

Chris, this feature has been requested for a long time. It's always 'under consideration'.

Chris DL5NAM

Guy, i know it very well. That's why i asking again. :-)

Tim - W4TME

If it is "under consideration", then we have heard you.

DrTeeth

It makes me wonder why Digital Audio Mode was considered for inclusion in SSDR before a dedicated RTTY mode with the release of the waveform API. Not seen a single request for the former, but I really wanted it anyway ;-).

I'm just asking out of curiosity and not to be difficult, honest :-).

Ken - NM9P

Digital AUdio mode gives us MANY additional digital modes in addition to RTTY.  all at the same time, just by using the Digi program suite of your choice.

BTW.  I have made a post with my RTTY work-around on the other "Native RTTY" thread here:
https://community.flexradio.com/flexradio/topics/rtty-native-mode

Perhaps it will help others set up a work-around until such time as Native RTTY is implemented by FRS or a third party using the Waveform API.
Ken - NM9P

km9r.mike

This !!!!  I think an option like this would be a semi game changer. I am not well versed in software engineering, but in my simple mind ( if we are talking the same thing ) if the software says a specific cw or rtty signal needs to be displayed at this position on the panadapter then I would think the left and right arrows on the keyboard could be utilized to jump up or down the band to the next adjacent signal instead of manually tuning to that signal. I have yet to hook up my flex control. I prefer using my mouse, however, if I could use keyboard arrows to immediately jump to zero beat of an adjacent signal now that would be special.