Rick, > On other thing that I can not understand is why THOR's performance > proved to be so poor on Tony's tests.
Dave points out that this could be a sample rate problem. Fldigi did just fine with other modes during the HF path simulations so the question is whether the sampling issue is unique to Thor or is the mode simply less tolerable to signal spread as the path simulator indicates. Tony, KHMU ----- Original Message ----- From: "Rick W" <[EMAIL PROTECTED]> To: <digitalradio@yahoogroups.com> Sent: Saturday, October 11, 2008 5:39 PM Subject: [digitalradio] THOR robustness or lack thereof > Great information, Dave, > > On other thing that I can not understand is why THOR's performance > proved to be so poor on Tony's tests. The robustness to multipath and > Doppler does not seem to show up although sensitivity at -15 dB SNR > seems quite good. > > It might be understandable with the more severe amounts such as high > latitude 7 msec path delay and 30 Hz Doppler, where the test indicated > no copy with THOR11 even at -3 dB SNR. > > But even at more modest low latitude 6 ms path delay with 10 Hz Doppler > and a -8 dB SNR there is still no copy. And most surprising is the > Mid-Latitude 2 ms path delay with only 1 Hz Doppler at -8 dB and THOR11 > was decoding only 80%. > > At most of these conditions, Olivia 500/16, and Olivia 500/8, and often > MFSK16, provided perfect copy and THOR11 showed no copy at all. > > Can anyone explain how this can be? > > 73, > > Rick, KV9U > > > David Freese wrote: >> The following is an excerpt from the web page "Sights and Sounds of >> Digital Signals", http://www.w1hkj.com/FldigiHelp/Modes/index.htm. >> >> THOR Modes >> >> General Description >> >> THOR is a family of offset incremental multi-frequency shift keyed >> modes with low symbol rate, closely related to DominoEX. A single >> carrier of constant amplitude is stepped between 18 tone frequencies >> in a constant phase manner. As a result, no unwanted sidebands are >> generated, and no special amplifier linearity requirements are >> necessary. The tones change according to an offset algorithm which >> ensures that no sequential tones are the same or adjacent in >> frequency, considerably enhancing the inter-symbol interference >> resistance to multi-path and Doppler effects. >> >> The mode has full-time Forward Error Correction, so is extremely >> robust. The default speed (11 baud) was designed for NVIS conditions >> (80m at night), and other speeds suit weak signal LF, and high speed >> HF use. The use of incremental keying gives the mode complete immunity >> to transmitter-receiver frequency offset, drift and excellent >> rejection of propagation induced Doppler. >> Protocol >> >> These are unconnected, manually controlled message asynchronous >> simplex chat modes, using binary convolutional Forward Error >> Correction. The default calling mode is THOR11. >> Coding and Character Set >> >> A binary varicode with ASCII-256 user interface (same as MFSK16) is >> used. Lower case characters are sent faster. An ASCII-128 secondary >> character set extension allows a fixed (typically ID) message to be >> sent whenever the transmitter is idle. Modulation uses two dibit >> pairs, symbol synchronous, differential. >> >> The FEC system uses binary convolution to generate two dibits per >> varicode bit, and halves the corrected data rate compared to the >> equivalent DominoEX mode. Rate R=1/2, Constraint length K=7, >> Interleaver L=10 (40 bits). >> Operating Parameters Mode Symbol Rate Typing Speed1 Duty Cycle2 >> Bandwidth3 ITU Designation4 >> THOR45 3.90625 baud 14 wpm 100% 173 Hz 173HF1B >> THOR55 5.3833 baud 22 wpm 100% 244 Hz 244HF1B >> THOR85 7.8125 baud 28 wpm 100% 346 Hz 346HF1B >> THOR116 10.766 baud 40 wpm 100% 262 Hz 262HF1B >> THOR16 15.625 baud 58 wpm 100% 355 Hz 355HF1B >> THOR22 21.533 baud 78 wpm 100% 524 Hz 524HF1B >> >> Notes: >> >> 1. WPM is based on an average 5 characters per word, plus word space. >> Values based on sending 100 "paris " words. >> 2. Transmitter average power output relative to a constant carrier of >> the same PEP value. >> 3. This is the "Necessary Bandwidth" as defined by the ITU. >> 4. A summary of the ITU Designation system can be found at >> http://en.wikipedia.org/wiki/Types_of_radio_emissions >> >> 5. Double spaced mode. >> 6. Default and normal calling mode. >> >> >> Implementation details are contained in the GPL software source code >> for fldigi which can be downloaded from the following site: >> >> http://www.w1hkj.com/fldigi-distro/fldigi-3.03.tar.gz >> >> This is a tar zipped format that will be familiar to all Unix, Linux, >> Free BSD and OS X developers. Windows developers can unzip this type >> of archive using one of several archive managers including PKZIP. >> >> Fldigi is open source source software that is licensed under the >> General Public License, http://www.gnu.org/copyleft/gpl.html. You are >> free to use the source intact, to modify, to improve and even to >> incorporate into a commercial product. You must however abide by the >> the license under which it has been developed and published. To date >> one other amateur product has used fldigi source with great success, >> DM-780, by Simon Brown. >> >> DominoEX-FEC and THOR differ in two ways: >> >> The FEC table structures in DominoEX-FEC have been manipulated in a >> way that prevents the transmission of control codes. THOR uses the >> same FEC table as MFSK and can transmit the full ASCII character set. >> The interleave used in THOR is longer than used in DominoEX-FEC, and >> it will have a slower throughput but greater immunity againts multi-path. >> >> Fldigi can encode and decode both DominoEX-FEC and THOR. >> >> 73, Dave, W1HKJ >> >> > >
