Does anyone have a link to the .dmg of FLDIGI 3.11.4? The latest .dmg I can find is 3.11.2 but there is a significant bug in the p-fsk output with that version that has been fixed in version 3.11.4.
Ian, Thanks. I neglected to look behind the curtain <G>. The p-FSK problem is an inversion of the stop bit ... it seems to have occurred in all OS for versions of fldigi prior to 3.11.4 and drove me
Dino, Thanks for the info. The problem I was chasing was an incorrect stop bit with the p-fsk code which has also been fixed in 3.11.4. Fldigi works very well by itself using the RIG-CAT interface -
The K3 has always had a dedicated RTTY decoder on the display as well as your choice of dedicated FSK or AFSK modes with dual-tone filter (DSP), real roofing filters of the appropriate bandwidth and
This is the "traditional" JA 160 meter allocation going back at least 30 years - far from new. 73, ... Joe, W4TV lans20090330.pdf 160m: 1907.5 - 1912.5kHz (New! but Narrow than 100Hz) 80m: 3520 - 35
That list isn't complete ... add the FT-9000 among others. In addition, any pair of Icom transceivers can be configured to use one as a second receiver (a perfect use for the second audio capability
That's true. Although the K4DSP FSK Regenerator will run on any AFSK software (and any soundcard) without the special p-FSK output, p-fsk is the only "supported" method for generating "true" FSK in
Bill, The appropriate ways to use RTTY are shown on page 20 of the IC-751A manual. In essence, the 24 pin Accessory plug can be "mapped" to the present 8-pin ACC(1) as follows: 8 pin IC-751A 3 3 PTT
250 Hz is really too narrow unless one has a high s/n and the interference is from a strong adjacent signal that is activating the AGC. As a first approximation the RTTY signal can be thought of as a
That document gives a "necessary bandwidth" of 250 Hz for 170 Hz shift 45.45 baud RTTY. However, that assumes phase continuous FSK and no data rate jitter ... as such it represents a best case and pr
Jeff, I don't believe you can consider the IF filter ("roofing filter") to be the only source of selectivity in any modern RTTY environment. Even the old "loading coil" TUs included some degree of ad
This is why the bandwidth of available filters seems to settle into the 350 Hz (Icom FL232) to 400 Hz (INRAD) range. While some might prefer a slightly wider bandwidth for normal CW, the 350 to 400
Check the DB37-FT-1000MP cable. Particularly, look for connection between pin 29 of the DB37 and pin 1 of the 4 pin DIN (RTTY) plug. See the schematic: www.microham-usa.com/Products/MK/Cables/DB37-F
Jim, I believe those stations have (accidentally?) moved the "Char wait" and/or "Diddle Wait" sliders in MMTTY from the left most positions. If I recall correctly, "Char Wait" will add extra space be
Jim, This can also be a symptom of an incorrect buffer setting in a traditional UART based serial port. Some software just "dumps" the message to the UART and then drops PTT after an arbitrary (short
There is no need to do that. MMTTY's "Limiting Speed" option simply sends one character every 165 msec (1.5 stop bits) or 176 msec (two stop bits). That avoids the need to watch for an echo - althou
Yes, you should be using "limiting speed" with MMTTY. It is slower but not excessively slow considering that the alternative is a major problem (early PTT drop, buffer issues, etc.) for FSK users. "
Putting RTTY activity of any kind - much less contest activity - in that heavily used CW spectrum in North America will start a range war and certainly renew calls for the ARRL to ask the FCC for mod
However, the poll was announced only on RTTY and not TopBand. Unless one was both a 160 meter regular and subscribed to RTTY, they would not have seen the poll announcement. It is interesting that t
Absolutely 1) RTTY is in traditionally CW portion of the band while AM activity is generally in the relatively clear area close to or above 1900 KHz. 2) RTTY with its continuous carrier is far more