AW: [digitalradio] Comparison of RTTY software sensitivity - New tests

2010-01-23 Thread Siegfried Jackstien
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

2010-01-22 Thread Patrick Lindecker
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

2010-01-22 Thread Wes Cosand
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

2010-01-22 Thread Patrick Lindecker
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

2010-01-22 Thread Wes Cosand
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