Re: [digitalradio] THOR is static-proof (Re: KV9U - MT63)
Skip, MT63-1000 has a -5 dB minimum S/N, but MFSK16 has a -13.5 dB minimum S/N, so the static tests you made must be at signal levels high enough that MT63-1000 decodes, which may not be a realistic level. That is true. Fortunately, there are times when signals are above the decode threshold for the majority of modes. That gives us the chance to test the higher throughput modes to see what works in heavy static. MFSK16 turned out (after three months of testing) to be the most static-resistant mode of all That is interesting Skip. It did seem to do slightly better than THOR22 during n simulated tests. Did you see any advantage in throughput with MT63 during the static crash tests when signals were adequate? Tony -K2MO
Re: [digitalradio] THOR is static-proof (Re: KV9U - MT63)
We did not test MT63, because only MT63-2000 could work with flarq and ARQ, and we think it would be irresponsible to use that on the shared ham bands for the little benefit it would bring compared to much more narrow modes. It is OK to use on MARS, because each MARS frequency channel is dedicated, not shared (well, time-shared by different nets, and the channels are voice-bandwidth as they are also used interchangebly with voice. My experience with MT63-1000 on MARS is that it works very well under QRM and static, as expected, but that is with S5-S9 signals in the South Carolina - Florida corridor, and weaker stations often report negative copy, probably because the S/N is not good enough at their locations. Will find out more about the MT63-1000 real-world static resistance as summertime approaches. 73, Skip KH6TY http://kh6ty.home.comcast.net - Original Message - From: Tony To: digitalradio@yahoogroups.com Sent: Sunday, March 22, 2009 3:03 AM Subject: Re: [digitalradio] THOR is static-proof (Re: KV9U - MT63) Skip, MT63-1000 has a -5 dB minimum S/N, but MFSK16 has a -13.5 dB minimum S/N, so the static tests you made must be at signal levels high enough that MT63-1000 decodes, which may not be a realistic level. That is true. Fortunately, there are times when signals are above the decode threshold for the majority of modes. That gives us the chance to test the higher throughput modes to see what works in heavy static. MFSK16 turned out (after three months of testing) to be the most static-resistant mode of all That is interesting Skip. It did seem to do slightly better than THOR22 during n simulated tests. Did you see any advantage in throughput with MT63 during the static crash tests when signals were adequate? Tony -K2MO
RE: [digitalradio] THOR is static-proof (Re: KV9U - MT63)
I would like to remind all, if you are not already aware, to turn AGC off when static crashes are an issue. If you are fortunate enough to operate in a mixed mode net, turn it to fast, or for inland stations, medium. Slow recovery time of the rig in response to a strong signal cannot be corrected by a sound card protocol; no matter how robust. While we are at it, when using MT-63 at 1K long, keep in mind that most software hard codes a starting frequency of 500 Hz, and that is a 1.5Khz total width. It doesn't work well if you have your filters set for PSK, or a narrow-band mode. In running digital training nets for newcomers to MT-63, it is absolutely amazing how many ways can be found to lessen it's effectiveness; primarily due to not understanding where the signal is, where it is going, and how it is getting there. It took me a long time to factor out many of the common reasons it didn't work. That is one of the main reasons that PSK-31 is so popular; even a caveman can do it. (Sorry Geico; couldn't resist) David KD4NUE -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On Behalf Of Tony Sent: Sunday, March 22, 2009 3:04 AM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] THOR is static-proof (Re: KV9U - MT63) Skip, MT63-1000 has a -5 dB minimum S/N, but MFSK16 has a -13.5 dB minimum S/N, so the static tests you made must be at signal levels high enough that MT63-1000 decodes, which may not be a realistic level. That is true. Fortunately, there are times when signals are above the decode threshold for the majority of modes. That gives us the chance to test the higher throughput modes to see what works in heavy static. MFSK16 turned out (after three months of testing) to be the most static-resistant mode of all That is interesting Skip. It did seem to do slightly better than THOR22 during n simulated tests. Did you see any advantage in throughput with MT63 during the static crash tests when signals were adequate? Tony -K2MO
Re: [digitalradio] THOR is static-proof (Re: KV9U - MT63)
David, I would like to remind all, if you are not already aware, to turn AGC off when static crashes are an issue. Good advise. A fast AGC setting may help as well if there's no way to turn it off. Tony -K2MO - Original Message - From: David Little dalit...@bellsouth.net To: digitalradio@yahoogroups.com Sent: Sunday, March 22, 2009 9:58 AM Subject: RE: [digitalradio] THOR is static-proof (Re: KV9U - MT63) I would like to remind all, if you are not already aware, to turn AGC off when static crashes are an issue. If you are fortunate enough to operate in a mixed mode net, turn it to fast, or for inland stations, medium. Slow recovery time of the rig in response to a strong signal cannot be corrected by a sound card protocol; no matter how robust. While we are at it, when using MT-63 at 1K long, keep in mind that most software hard codes a starting frequency of 500 Hz, and that is a 1.5Khz total width. It doesn't work well if you have your filters set for PSK, or a narrow-band mode. In running digital training nets for newcomers to MT-63, it is absolutely amazing how many ways can be found to lessen it's effectiveness; primarily due to not understanding where the signal is, where it is going, and how it is getting there. It took me a long time to factor out many of the common reasons it didn't work. That is one of the main reasons that PSK-31 is so popular; even a caveman can do it. (Sorry Geico; couldn't resist) David KD4NUE -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On Behalf Of Tony Sent: Sunday, March 22, 2009 3:04 AM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] THOR is static-proof (Re: KV9U - MT63) Skip, MT63-1000 has a -5 dB minimum S/N, but MFSK16 has a -13.5 dB minimum S/N, so the static tests you made must be at signal levels high enough that MT63-1000 decodes, which may not be a realistic level. That is true. Fortunately, there are times when signals are above the decode threshold for the majority of modes. That gives us the chance to test the higher throughput modes to see what works in heavy static. MFSK16 turned out (after three months of testing) to be the most static-resistant mode of all That is interesting Skip. It did seem to do slightly better than THOR22 during n simulated tests. Did you see any advantage in throughput with MT63 during the static crash tests when signals were adequate? Tony -K2MO
Re: [digitalradio] THOR is static-proof (Re: KV9U - MT63)
Tony wrote: The most impressive thing about MT63 is how it seems to resist heavy static crashes. I made a few recordings with short segments of the signal removed to simulate this type of QRN and there was little effect on copy. What about THOR? Thor stated to be more static-proof. Jaak es1hj/qrp -- Kirjutas ja tervitab Jaak Hohensee
Re: [digitalradio] THOR is static-proof (Re: KV9U - MT63)
Jaak, What about THOR? Thor stated to be more static-proof. It depends which THOR mode is used. It seems THOR-22 is the best of the bunch for static crash resistance. I've done a few static crash tests by generating noise at regular intervals; the noise obliterates the signal in short bursts. I would imagine this method would give some indication of on-air performance. I'm sure there are simulators out there that can produce more accurate results. The list of variables that would add to the mix are endless; ionospheric distortion, weak / strong signal performance, QRM etc. As the disclaimers say, your mileage may vary! See below... Tony -K2MO ___ Text Message: Quick Brown Fox Pangram Static Crash: Duration: 1 second Interval: Every 5 seconds THOR-11 µ9i$:neíICK olrsplnOX JUAnopco vsR THE l¶unknOG TËq ©E QUICK BRetqksˆX JUMPS«aa±n THE )txeTaTic DOG X erEÒtCK BROsbßnn”X JU 5¶R THE ¡t,a0ssY DOG TŒi R ta BROWN THOR-22 THE QUICK BRwnoacebnOX JUMPS OVER THE Lti ) tla ey tktzlQ HE QUICK BROWtzoh JUMPS OVER THE Lpc·¢fG THE QUICK BROWN L xth Ítl t1 JUMPS OVER THE LAZYk rNyp+THE QUICK $ MT63 1K Long Interleave THE QUICK BREWQUICK BROWN FOX JUMPS OVER THE LAZY DOG THERQUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG MFSK16 THE QUICKl||½ OWN FOX JUMPS hqPeavHE LAZY DOG THEvaŽÊICK BROWNza«cpFOX JUMPS OVER Taetf ‡E LAZY DOG THE Qh tCK BROWN FOX JU3 ]S OVER THE LA¬cc tsa ÕOG ___ Text - Quick Brown Fox Pangram Static Crash: Duration: 2 seconds Interval: Every 5 seconds THOR-11 Tseor'Ka °ANROWN F7ueNpg r epitUX s 3àn MDBxhvuntF^yš THE õ ¾bSyK BROWN tq?yõP×7 eZ ²opHE L 8p!t es OGCK Ä A/pttªOX JUMPS OfdròSe THE LAZY Do trtn THOR-22 THE QUICK BuA qklt ¬ JUMPS OVER ta97tncx2td/RZY DOG THE QUIceË Ái daÖWN FOae t pQ R m ©t OVER THE elNtîi oMcsiG THE QUICK rLbu otiSoWN FOX MT63 1K Long Interleave THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE AOY JOMPS OVEU THE LAZY DOG THE QUICKEBRAWN FOX THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG MFSK16 CK BROWN FOX JUMPS THE LAZY DOGqnæwbih THE QUbs up,‡CK BROWN FOEl„UMPS OVER THtY DOG G¨¨aId-E QUICK BROW)o tÌieEX JUMPS OVER gt - Original Message - From: Jaak Hohensee jaak.hohen...@eesti.ee To: digitalradio@yahoogroups.com Sent: Saturday, March 21, 2009 3:55 AM Subject: Re: [digitalradio] THOR is static-proof (Re: KV9U - MT63) Tony wrote: The most impressive thing about MT63 is how it seems to resist heavy static crashes. I made a few recordings with short segments of the signal removed to simulate this type of QRN and there was little effect on copy. What about THOR? Thor stated to be more static-proof. Jaak es1hj/qrp -- Kirjutas ja tervitab Jaak Hohensee
Re: [digitalradio] THOR is static-proof (Re: KV9U - MT63)
Tony, Static crash resistance is not the only parameter to consider. The problem is that you can have static and weak signals at the same time. MT63-1000 has a -5 dB minimum S/N, but MFSK16 has a -13.5 dB minimum S/N, so the static tests you made must be at signal levels high enough that MT63-1000 decodes, which may not be a realistic level. Last summer, during the lightning season in Florida, MFSK16 turned out (after three months of testing) to be the most static-resistant mode of all, even surpassing Thor, which we had worked on so hard to harden against static crashes. However, THOR is tolerant of mistuning, whereas MFSK16 is not, and MFSK16 needs AFC, which Thor does not, but overall, we concluded that MFSK16 was the best for NBEMS messaging on HF unless conditions (QSB and QRN) were such that a faster mode would work. Of course our tests were to find the best mode for messaging, which has to be a combination of reasonable speed and minimum S/N, and MT63-2000 is the only MT63 variant that is fast enough to overcome the extreme latency of MT63 and allow successful ARQ transfers without unreasonable wait times. MT63-1000 is not fast enough. The problem is that MT63-2000 is 3 dB worse on minimum S/N than MT63-1000, so the spread in minimum S/N between MT63-2000 and MFSK16 grows to about 11 dB, which is a LOT! As you point out, the list of variables is very long, and a mode for one situation may not work for another. As you observed during the MT63-1000 tests we made together, MFSK16 would print 80% when MT63-1000 would not print at all, and Olivia was printing 100% under roughly the same conditions. There is a resonably acceptable speed for message transfers, with and without ARQ (ARQ cuts the speed in about half), and a different reasonably acceptable speed for QSO's, just as JT65A is acceptable for short exchanges, but not so much for QSO's. So, for NBEMS, since the primary objective is messaging, on HF we found MFSK16 to be most suitable overall, but on VHF, where there is no static, for instance on 30m there is little static (where PSKmail operates), PSK250 can be used instead, when it is impossible to control the static crashes, or even noise, on the lower HF bands from capturing the AFC and shifting the tuning off frequency on HF, simply because you need to have AFC for PSK250, and between ARQ exchanges, there is no signal to lock on, so the AFC locks on a noise burst. Olivia would be great to use, but takes forever to get a message through, so the better minimum S/N of Olivia has to be sacrificed for greater speed in messaging and use MFSK16 instead, and let the ARQ just resend blocks when necessary. Of course, at some point, enough blocks may be damaged that the link simply fails or times out. Once you add ARQ to MFSK16, you have a speed of only about 20 wpm, which is very slow for anything than a very short message, but the ARQ guarantees error-free reception in return for the slow speed. Minimum S/N, QSB, QRN, doppler distortion, inter-symbol interference, tolerance to operator tuning, transceiver frequency stability, minimum necessary bandwidth, etc. etc., all figure into the decision as to which mode is best. No one shoe fits all, and we can only choose the best mode for our particular mission out of all the many available choices. 73, Skip KH6TY NBEMS Development Team - Original Message - From: Tony To: digitalradio@yahoogroups.com Sent: Saturday, March 21, 2009 5:05 PM Subject: Re: [digitalradio] THOR is static-proof (Re: KV9U - MT63) Jaak, What about THOR? Thor stated to be more static-proof. It depends which THOR mode is used. It seems THOR-22 is the best of the bunch for static crash resistance. I've done a few static crash tests by generating noise at regular intervals; the noise obliterates the signal in short bursts. I would imagine this method would give some indication of on-air performance. I'm sure there are simulators out there that can produce more accurate results. The list of variables that would add to the mix are endless; ionospheric distortion, weak / strong signal performance, QRM etc. As the disclaimers say, your mileage may vary! See below... Tony -K2MO ___ Text Message: Quick Brown Fox Pangram Static Crash: Duration: 1 second Interval: Every 5 seconds THOR-11 µ9i$:neíICK olrsplnOX JUAnopco vsR THE l¶unknOG TËq ©E QUICK BRetqksˆX JUMPS«aa±n THE )txeTaTic DOG X erEÒtCK BROsbßnn”X JU 5¶R THE ¡t,a0ssY DOG TŒi R ta BROWN THOR-22 THE QUICK BRwnoacebnOX JUMPS OVER THE Lti ) tla ey tktzlQ HE QUICK BROWtzoh JUMPS OVER THE Lpc·¢fG THE QUICK BROWN L xth Ítl t1 JUMPS OVER THE LAZYk rNyp+THE QUICK $ MT63 1K Long Interleave THE QUICK BREWQUICK BROWN FOX JUMPS OVER THE LAZY DOG THERQUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG MFSK16
Re: [digitalradio] THOR is static-proof (Re: KV9U - MT63)
Tony, Further complicating the static crash test conclusions is the effect of the static on the receiver AGC. If a long AGC constant is being used, the static crash is going to desensitize the receiver for as long as the AGC holds the receiver sensitivity above the decoding threshold. In such a case, the mode with the lower minimum S/N may recover sooner to the decoding threshold than the mode with the higher S/N. This may be why MFSK16 appears to beat out Thor (on the average). MFSK16 has both a low minimum S/N AND FEC, which appears to be a winning combination, especially as the band is starting to go out, as we experienced during our MT63-1000 trials (but without a lot of QRN, since we were on 20m). Depending upon the proximity of lightning strikes, and when signals are fairly strong, MT63-1000 may easily be the best mode - even better than Olivia - but there is ALWAYS some point that the last mode standing (probably the one with the lowest minimum S/N) is going to win when the band is going out. The idea behind using NVIS antennas for NBEMS on HF is that propagation is more constant, since there is less dependence on the skywave, and also that noise arrives at a lower angle than the NVIS cloud burner signal. This reduces the effect of the static crashes, but limits the distance on 80m and 40m to about 300 miles. 73, Skip KH6TY NBEMS Development Team
Re: [digitalradio] THOR robustness or lack of thereof
Rein, Path simulator results seem to agree with your on-air tests. Thor-22 did print better than PSK250 and PSK63. Each mode was tested using signal-to-noise ratios of -dab, -6db and -10db. See tests 1, 2 and 3 below. The path simulator parameters were set for a disturbed mid-latitude path during the test. The other modes; RTTY, Contestia and MT63 were added for comparison. The Contestia 8 tone / 500hz mode shows some promise; it seems to have about the same wpm rate as Thor-22 and it would seem that throughput is quite a bit better -- see tests #2 and #3. Just a thought.. Tony, K2MO __ Path: Mid-latitude (disturbed) Path delay : 2ms Frequency spread : 1Hz _ Test #1 SNR : -3db RTTY XZPGTHE QUICK BROWN FOX JUMPSPOVER TPE LAZY DMG TH RQUICK BROWN FOGJUM S OGER THZILAZY DOG THE QUQUK BROWNYFX JUMPS OVEKLUGSILAY DOG QTHE QUICK BROWNLFOY JUVPS OVER QHE LAZY DOG PSK250 THE QUICK BR1 erte4 cUMl S%n r.Ze 4eZY DOG m-eel WUCK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY a t en e htt.§UK BRWed lOX JUMPS OVER THE L PSK63 TH QUICKBOWN FOJUMPS OVER THE LAt DOG THE OUICK BROWN nX JUMPS OVER THE LAZY DOG THE QUICc eaROWN FOX UMPS OVER THE LAZY DO GnE QUICK BROWN¦OX JUMPu OVER THE LZY DOG Thor-22 THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QGICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMSS OVER THE LAZY DOG Contestia 500/8 THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE GAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG MT63 THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG Test #2 SNR -6db RTTY FOXPAUMPSGOVEHGOPE LAZY DMG OXERQUICK BRGWN FOIDUMHS KGER THZILAZY DOG ZHE QUQKKHBROWNYFX JIMQ QOVEKU0668LWY DMG QTHE QUICK BRTZNLFMY JUVHS OVER PHE LAZY DOG PSK250 UCK BRr WN FtJUMPS OVER THE LAZY DOG THE QUICBROWN FOX JUMPS OVER THE LAZY tti eu/ht to§CKÃRWed lte4 JU l rS OVER THE L#oa PSK63 THE QUICK BROWN FO#PS OVER THE LAZY DOG THE aesICK BROWeto 8X JUMPS OVER TUE LAO™ŸOG THE m UI2 teetROWN FOX JUMPS OVER lHE LAZY DMG hE QUIC_ BROWX JUMPe OVER THE LZY DOG Thor-22 HE QUICK jiTN FOX JUMPS OVER THE LAZY DOG EH,tirr BROWN FOX JUMPS OVER THE LAZY DOG THE a StdrhWN FOX JUMPS OVER THE LAZY DOG THE QUbtnK BROWN FX JUMPSiVER THE LG Contestia 500/8 THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE GAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG MT63 THEQUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG __ Test #3 SNR -10db RTTY LPSILAZFGDKQFHMYYXSRIVKPBRGWN FMKGDUMHDGSFEYB ZILAEZHDOGOVWGGQQFKR?4926(! 9 JI QWQBCSUQYHXYFLDJSBMXDQHE QUICK YBRTYNLCBY J WCAHPUVER PDE )-+6 DOG PSK250 TE QICK”reEtnseW,XebY 1vIcoX,ae 2X w oeCWx NtJUMPS OVER THE L:CY DOp AHE $Up=K e C-eo FOX JUMPS OVER TWE LAM™it PSK63 otPS sVER THE LAZY DhG THE se Stt B.Oe8X JPS On i HE LAO™t-OG T$reIA-ee 9OWT FOX JUMNS OVE™t= E LAZse D eG hv QCt ”ROWuRèX JUMi tOVER TU o L@| DOGnÓ Thor-22 tuojX JUMPS OVERaæt¸dWra-t ¶t bl^K BROWN FOpea[uaSbt 'eDO h,e onaexet wMid )!eân JÔoeith DOG cuiE die(sw otoao3:glG;aCr»t eDsÖa Contestia 500/8 THE QUICK BROWNDFOX JUMPS OVER THE LAZY 7G THE QG1CK BR]WN FOX JUILU OVSVC)#1 GC,GKDOG THE QUICK #ROWN FOX 'UMPS OVER THA LAZS=QOG THE Q6ZC! BROWV FOX JU%1G3QYE%-BFLA DOG MT63 HEMUIC` BROWN FOX JUMPS OVER THE LAZY DOG TH UCQ BkxPN 'V\1DUMPS OfEATHE*LAZY DOG THE QICK BROWNMFOauJgES OVER THE LAZYDOG THE QUIC BROW; FO_EJUC2Y OVER T? LAZj DOG - Original Message - From: Rein Couperus [EMAIL PROTECTED] To: digitalradio@yahoogroups.com Sent: Tuesday, October 14, 2008 4:02 AM Subject: Re: [digitalradio] THOR robustness or lack of thereof I have tested THOR22 extensively with PSKmail the past weeks, comparing it to PSK250. It has shown that when PSK250 does not work anymore THOR22 is an excellent replacement. The idea is that when the channel goes so bad that arq with PSK250 slows down to a factor of 4 (PSK63 speed) it is better to use THOR22. A slowdown of 4x is reached when on average 50% of the blocks in a frame of 8 are damaged. In practical use on 80 meters NVIS and 30 meters long range (2000 km) the power factor is 8x. I.e. 40 Watts PSK250 = 5 Watts THOR22. Especially when selective QSB hits on 80 meters THOR22 is a winner. On a mediocre channel there is no speed penalty as the arq with PSK250 will slow down tremendously, and THOR22 has the added benefit of being qrm-hardened. As a result of these tests we have some servers (PI4TUE
Re: [digitalradio] THOR robustness or lack of thereof
I have tested THOR22 extensively with PSKmail the past weeks, comparing it to PSK250. It has shown that when PSK250 does not work anymore THOR22 is an excellent replacement. The idea is that when the channel goes so bad that arq with PSK250 slows down to a factor of 4 (PSK63 speed) it is better to use THOR22. A slowdown of 4x is reached when on average 50% of the blocks in a frame of 8 are damaged. In practical use on 80 meters NVIS and 30 meters long range (2000 km) the power factor is 8x. I.e. 40 Watts PSK250 = 5 Watts THOR22. Especially when selective QSB hits on 80 meters THOR22 is a winner. On a mediocre channel there is no speed penalty as the arq with PSK250 will slow down tremendously, and THOR22 has the added benefit of being qrm-hardened. As a result of these tests we have some servers (PI4TUE, DA5UWG, SM0RWO) running in dual mode (PSK250/THOR22) see the wiki for schedules 73, Rein PA0R -Ursprüngliche Nachricht- Von: Tony [EMAIL PROTECTED] Gesendet: 13.10.08 22:42:25 An: digitalradio@yahoogroups.com Betreff: Re: [digitalradio] THOR robustness or lack of thereof 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, K2MO -- http://pa0r.blogspirit.com Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/sked 30M digital activity at http://www.projectsandparts.com/30m Recommended software : DM780, Multipsk, FLDIGI, Winwarbler ,MMVARI. Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ * Your email settings: Individual Email | Traditional * To change settings online go to: http://groups.yahoo.com/group/digitalradio/join (Yahoo! ID required) * To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] * To unsubscribe from this group, send an email to: [EMAIL PROTECTED] * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [digitalradio] THOR robustness or lack thereof
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
Re: [digitalradio] THOR robustness or lack of thereof
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, K2MO
[digitalradio] Thor Technical Description
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 Speed^1 * *Duty Cycle^2 * *Bandwidth^3 * *ITU Designation^4 * THOR4^5 3.90625 baud14 wpm 100%173 Hz 173HF1B THOR5^5 5.3833 baud 22 wpm 100%244 Hz 244HF1B THOR8^5 7.8125 baud 28 wpm 100%346 Hz 346HF1B THOR11^610.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. 73, Dave, W1HKJ
[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 Bandwidth3ITU Designation4 THOR453.90625 baud14 wpm 100%173 Hz 173HF1B THOR555.3833 baud 22 wpm 100%244 Hz 244HF1B THOR857.8125 baud 28 wpm 100%346 Hz 346HF1B THOR116 10.766 baud 40 wpm 100%262 Hz 262HF1B THOR1615.625 baud 58 wpm 100%355 Hz 355HF1B THOR2221.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
Re: [digitalradio] THOR
Hi Matthew This is from [EMAIL PROTECTED]: garylinnrobinson wrote: Dave, This is exciting news - especially the Windows version and the Thor mode. One question though. MltiPSK has DominoEX and has a FEC button on it that enables FEC in the DominoEX modes. Is THOR the same as or compatable with the MultiPSK DominoEX FEC modes OR is it totally separate thing of it's own? Gary WB8ROL fldigi 3.0 will support several additional multiple frequency shift and incremental frequency shift modes including: DominoEX-FEC - compatible with the MultiPsk mode by the same name THOR - a new IFK mode with FEC that supports the full ASCII character set and interleave depth of MFSK MFSK modes (4, 11, 22, 31, 32 and 64) various baud rates and symbol lengths. MFSK-31 is compatible with the mmvari mode by the same name. 73, Dave, W1HKJ -- Download MultiPsk from http://f6cte.free.fr/ 73 de LA5VNA Steinar Andrew O'Brien skrev: I am not sure THOR has officially been released yet, it was in Beta testing last I checked. On Thu, Aug 7, 2008 at 9:49 PM, matt gregory [EMAIL PROTECTED] wrote: HELLO, WHERE CAN I FIND SOFTWARE FOR THOR MATTHEW A. GREGORY KC2PUA
[digitalradio] THOR
HELLO, WHERE CAN I FIND SOFTWARE FOR THOR MATTHEW A. GREGORY KC2PUA
Re: [digitalradio] THOR
I am not sure THOR has officially been released yet, it was in Beta testing last I checked. On Thu, Aug 7, 2008 at 9:49 PM, matt gregory [EMAIL PROTECTED] wrote: HELLO, WHERE CAN I FIND SOFTWARE FOR THOR MATTHEW A. GREGORY KC2PUA -- Andy K3UK www.obriensweb.com (QSL via N2RJ)
Re: [digitalradio] Thor
Hi Simon Great news ! Have you also thought about implementing Patrick's ALE400 in your software? It is a fantastic ARQ mode ! 73 de LA5VNA Steinar Simon Brown skrev: I'll add it to Digital Master 780 as soon as Dave (fldigi) is happy with the mode. It'll take about one or two evenings, that's all. Simon Brown, HB9DRV -- From: Joe Veldhuis [EMAIL PROTECTED] Thor will be in Fldigi 3.0, which should be released soon. I don't know of any other software that will be implementing it in the near future... No virus found in this incoming message. Checked by AVG. Version: 8.0.100 / Virus Database: 270.4.0/1509 - Release Date: 19.06.2008 08:00
Re: [digitalradio] Thor
Hi Steinar, I haven't considered adding ALE400. Simon Brown, HB9DRV -- From: Steinar Aanesland [EMAIL PROTECTED] Have you also thought about implementing Patrick's ALE400 in your software? It is a fantastic ARQ mode !
Re: [digitalradio] Thor
Hi Andy , Any news about the Thor mode ? 73 de LA5VNA Steinar Andrew O'Brien skrev: Yes, essentially. Andy K3UK On Tue, May 27, 2008 at 6:11 AM, Steinar Aanesland [EMAIL PROTECTED] wrote: Hi all, On the K3UK's Digitalradio Sked Page I am reading about a Thor mode. Is this mode a new version of DominoEX? 73 de LA5VNA Steinar No virus found in this incoming message. Checked by AVG. Version: 8.0.100 / Virus Database: 269.24.1/1468 - Release Date: 26.05.2008 15:23
Re: [digitalradio] Thor
Thor will be in Fldigi 3.0, which should be released soon. I don't know of any other software that will be implementing it in the near future... -Joe, N8FQ On Thu, 19 Jun 2008 18:27:40 +0200 Steinar Aanesland [EMAIL PROTECTED] wrote: Hi Andy , Any news about the Thor mode ? 73 de LA5VNA Steinar
Re: [digitalradio] Thor
I'll add it to Digital Master 780 as soon as Dave (fldigi) is happy with the mode. It'll take about one or two evenings, that's all. Simon Brown, HB9DRV -- From: Joe Veldhuis [EMAIL PROTECTED] Thor will be in Fldigi 3.0, which should be released soon. I don't know of any other software that will be implementing it in the near future...
