AW: [digitalradio] Comparison of RTTY software sensitivity - New tests
6 year old grandson ? does he hold a license ??? just kidding Okay all of us know that ham radio has not many newcomers . Give him a radio as birthday present maybe a bit young with 6 years but if not this year maybe a bit later 73´s dg9bfc Sigi _ Von: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] Im Auftrag von Wes Cosand Gesendet: Samstag, 23. Januar 2010 02:00 An: digitalradio@yahoogroups.com Betreff: Re: [digitalradio] Comparison of RTTY software sensitivity - New tests On Fri, Jan 22, 2010 at 7:44 PM, Patrick Lindecker f6...@free.fr wrote: Hello Wes, I saw the test file. It is nice except the long suite of figures, which could be a cause of possible systematic failure (with many errors following a first error) . Better would be to keep only the call signs which include figures and letters and produce a good diversity (and so a more precise statistic result). Also it would be perhaps interesting to transmit the RTTY characters through 2 different programs because a program could produce a not exactly nominal RTTY transmission and its decoding could match this transmission (for example, the stop must be 1.5 bits but can vary in fact). If, with two different transmissions, the results are the same, they can be considered as reliable. 73 Patrick Good suggestions, Patrick. I will get it done. But first I must go to a birthday party for my 6 year old Grandson! I have to have my priorities right... HI HI Wes, WZ7I
[digitalradio] Comparison of RTTY software sensitivity - New tests
Hello Wes and all, I tried here Multipsk versus Mixw at -9 dB of S/N in RTTY 45 (I have not TRUETTY but they seem to be equivalent). I tested with a text and the Multipsk decoding was better than the Mixw one . However, in RTTY the ITA2 set of character is used so it is difficult to compare because figures instead of letters can be seen as bad whereas there are good in fact (simply due to a random switching) . So I tested with C8C8C8C8C8C8C8C8C8C8 to avoid not this problem. I confirmed that the Multipsk RTTY decoding is better than the Mixw one (I don't think to have a partial opinion, I hope so...). But Multipsk could work better on this particular characters, so I tried with 1A2B3C4D5E6F7G8H9...which is a diversified sequence. I got 135 characters OK with Multipsk and 107 on Mixw. In both softs, I set the AFC Off and I tested with a confortable level (about 40 % of the maximum in average, taken on the Multipsk level), same exact AF frequency (830/1000 Hz). Note 1: I used a sound blaster sound card to send the signal which was decoded by both softs (input plugged with the output). Note 2: the decoding on Multipsk and Mixw is almost perfect (only few errors) at about -5.5 dB. 73 Patrick - Original Message - From: Wes Cosand To: digitalradio@yahoogroups.com Sent: Thursday, January 21, 2010 3:05 AM Subject: Re: [digitalradio] Comparison of RTTY software sensitivity On Wed, Jan 20, 2010 at 8:06 PM, Dave AA6YQ aa...@ambersoft.com wrote: Thanks Wes. WinWarbler uses MMTTY as its RTTY engine; thus MMTTY can be configured to achieve the same performance as that shown for WinWarbler. Yes, I certainly did not mean to construct a test to show MMTTY at a disadvantage. I assumed folk would realize that the engine is the same in the two packages. I wanted to see if there was a difference between the Hyper Sensitive profile (which exists as a predefined profile only in WinWarbler) and the Standard profile which is the default in both packages. I was surprised after the tests to see the significant difference in performance made by inserting the notch filter between the mark and space frequencies. TrueTTY would seem to deserve wider attention. I have used UA9OV's CW Get for a number of years to zero beat my CW and perhaps I should keep a copy his TrueTTY running as a second receive modem when I work RTTY. Wes, WZ7I
Re: [digitalradio] Comparison of RTTY software sensitivity - New tests
Patrick, thank you for your kind note. I discovered, as you have known for a long time, that testing RTTY is not easy because of random figures/letters shifts. As you said, a single inappropriate shift can mess up a lot of characters! That makes the statistics difficult. My test text file is at http://mysite.verizon.net/wz7i/Text%20file%20for%20testing%20communications%20software.html I used call signs and about 30% five number groups to try to deal with this issue. I tested with UOS off because of the number groups. It may be that I should have used a shorter file and then tested it with different audio files a number of times to get reasonable statistics but that seemed too much work... chuckle... The error bars on the graph might have been significant. Instead I tried to run a long enough text file to average out all the random shifts. It probably wasn't long enough to try to analyze the data too closely. I, too, tested with AFC off. I used the audio frequencies used for FSK so that is a difference. Our audio levels were about the same -- 40% sounds about right. As I said earlier, it is possible that I have incorporated some error in my methods. It is possible that I am straining at gnats and swallowing camels :-) Thank you for your patience with me. 73 de Wes, WZ7I
Re: [digitalradio] Comparison of RTTY software sensitivity - New tests
Hello Wes, I saw the test file. It is nice except the long suite of figures, which could be a cause of possible systematic failure (with many errors following a first error) . Better would be to keep only the call signs which include figures and letters and produce a good diversity (and so a more precise statistic result). Also it would be perhaps interesting to transmit the RTTY characters through 2 different programs because a program could produce a not exactly nominal RTTY transmission and its decoding could match this transmission (for example, the stop must be 1.5 bits but can vary in fact). If, with two different transmissions, the results are the same, they can be considered as reliable. 73 Patrick - Original Message - From: Wes Cosand To: digitalradio@yahoogroups.com Sent: Saturday, January 23, 2010 12:42 AM Subject: Re: [digitalradio] Comparison of RTTY software sensitivity - New tests Patrick, thank you for your kind note. I discovered, as you have known for a long time, that testing RTTY is not easy because of random figures/letters shifts. As you said, a single inappropriate shift can mess up a lot of characters! That makes the statistics difficult. My test text file is at http://mysite.verizon.net/wz7i/Text%20file%20for%20testing%20communications%20software.html I used call signs and about 30% five number groups to try to deal with this issue. I tested with UOS off because of the number groups. It may be that I should have used a shorter file and then tested it with different audio files a number of times to get reasonable statistics but that seemed too much work... chuckle... The error bars on the graph might have been significant. Instead I tried to run a long enough text file to average out all the random shifts. It probably wasn't long enough to try to analyze the data too closely. I, too, tested with AFC off. I used the audio frequencies used for FSK so that is a difference. Our audio levels were about the same -- 40% sounds about right. As I said earlier, it is possible that I have incorporated some error in my methods. It is possible that I am straining at gnats and swallowing camels :-) Thank you for your patience with me. 73 de Wes, WZ7I
Re: [digitalradio] Comparison of RTTY software sensitivity - New tests
On Fri, Jan 22, 2010 at 7:44 PM, Patrick Lindecker f6...@free.fr wrote: Hello Wes, I saw the test file. It is nice except the long suite of figures, which could be a cause of possible systematic failure (with many errors following a first error) . Better would be to keep only the call signs which include figures and letters and produce a good diversity (and so a more precise statistic result). Also it would be perhaps interesting to transmit the RTTY characters through 2 different programs because a program could produce a not exactly nominal RTTY transmission and its decoding could match this transmission (for example, the stop must be 1.5 bits but can vary in fact). If, with two different transmissions, the results are the same, they can be considered as reliable. 73 Patrick Good suggestions, Patrick. I will get it done. But first I must go to a birthday party for my 6 year old Grandson! I have to have my priorities right... HI HI Wes, WZ7I