| |
VE2HAR > MT63 15.03.05 21:47l 286 Lines 7338 Bytes #-7001 (0) @ WW
BID : 23225SENTTO
Read: GUEST
Subj: Re: [MT63]
Path: DB0FHN<DB0FOR<DB0SIF<DB0FHK<DB0FBB<DB0IUZ<DB0GOS<DB0EEO<DB0RES<ON0BEL<
VE2PAK<W1NGL<VA2HAR<VE2HAR
Sent: 050315/1913z @:VE2HAR.#MTL.QC.CAN.NOAM Laval #:42840 $:23225sentto
Hi there...
Yea, the M$ windoze name is chkfile... Sorry. Same idea...
You are correct, as I was neglecting the older RTTY modes. Should be a=20
text file...
dubose@texas.net wrote:
>Hi Steve,
>
> =20
>
>>Point 1. Checking the byte size will not tell you anything other than i=
f=20
>>a byte is added or missed. Checksum is the correct way to do that. It=20
>>adds all of the data together to creat a binary number. Filecheck also=20
>>works by doing a direct comparison byte by byte of the data and giving=20
>>an indication of where the error or discrepancy is.
>> =20
>>
>
>Yes...didn't I say an MD5 check (isn't that a checksum?)? I think that =
would be
>a better check.
>
>Filecheck??? Is that a MS command or Unix command? In Unix its "diff" o=
f the
>difference between two files. I've been away from REAL Unix for such a =
long
>time that I have forgotten the commands. Hi Hi.
>
> =20
>
>>Point 2. 3,000 words is not less than 3,000 bytes. That would be closer=
=20
>>to (8 bits/byte X 5 Bytes/word + spaces and puncuation) 144,000 which a=
t=20
>>200WPM would take 12 minutes to send.
>> =20
>>
>
>
>Hummm, my math was probably wrong also...400 words=3D2400 characters and=
with 8
>bit and start and stop bits that's 10 bits per character so 2400 * 10 =3D=
24KBPS.
> Is that right? Well that might be a little large.
>
> =20
>
>>The file needs to be a bit smaller. I recommend a small gif or bmp file=
=20
>>of a test pattern. 1) so that it is able to be sent within 3 - 4=20
>>minutes, not over 10 minutes for ID purposes. 2) A quick visual=20
>>inspection of the file would show gross errors.
>> =20
>>
>
>The problem here is that if you want to apply the same file to MFSK16 or=
AMTOR
>or RTTY or AX.25 for comparison, the binary file wouldn't work...so we n=
eed text.
>
>Walt/K5YFW
>
> =20
>
>>Steve/WM5Z
>>
>>karl larsen wrote:
>>
>> =20
>>
>>> Hi Walt, I agree we need to define our text that we send, the amount=20
>>>of bytes that are sent and then have a method to check the number of=20
>>>errors. The size can be more than 3 Kbytes but no larger is better. Th=
e=20
>>>text can be anything but it must conform with the ASCII text format. T=
he=20
>>>test text must be sent to this list so everyone that is interested can=
=20
>>>get the accurate file. In linux you can check both files by knowing=20
>>>there total byte size. If they are the same, it's perfect. You get the=
=20
>>>byte size with ls -al.
>>>
>>>Using the Linux gMFSK I can send the test file directly with clicking=20
>>>File and then Send file. When I receive the test file I can simply cut=
=20
>>>it out of my lof file. I have my system set to log everything. Fun to=20
>>>look at later.
>>>
>>>I have a file we can use. It is the ARRL bandplan. It is way too long=20
>>>but I will cut it down to about 3,000 words.
>>>
>>>karl
>>>
>>>
>>>dubose@texas.net wrote:
>>>
>>>=20
>>>
>>> =20
>>>
>>>>Thanks to Patrick, F6IN, for bringing PathSim to our attention. This=
is truly a
>>>>nice application.
>>>>
>>>>Building on what I believe Tomi or others have said, as well as my ow=
n thoughts
>>>>about having a "test" file. Also, looking at G4HPE's papers found at
>>>>http://www.rsgb.org/emergency/datamodesinfo.htm . And not to be left=
out, my
>>>>several E-Mails with Charles, G4GUO.
>>>>
>>>>Back in Jan/Feb of 1990, the US TRANSCON began "testing", on-the-air,=
HF
>>>>transmissions of a file which became their standard. It was a 40KB =
file. The
>>>>modes being used were the MIL-STD-188-110 type. These were interesti=
ng test.=20
>>>>The MD5 sum was used on each received file to verify that its was the=
same as
>>>>the original file. Throughput and accuracy were important.
>>>>
>>>>G4HPE in his paper "A PRACTICAL EVALUATION AND COMPARISON OF SOME MOD=
ERN DATA
>>>>MODES" (http://www.rsgb.org/emergency/articles/datmodes2.pdf) Richard=
speak of
>>>>the test he did on MT63 and MFSK16.
>>>>
>>>>Also, on page 17 of Rick=92s, KN6KB, presentation to the DCC last Sep=
tember
>>>>(2004), he shows throughput using an HF channel simulator from KC7WW=92=
s Oregon
>>>>Software Factory.
>>>>
>>>>G4HPE=92s test concluded that MT63 had a throughput of 200 WPM at a =96=
5 dB SNR on a
>>>>poor CCIR Channel. KN6KB=94s results for Pactor II/III indicate a si=
milar (if not
>>>>lower) throughput under the same signal conditions.
>>>>
>>>>While I do not doubt these findings, I believe that as some in this g=
roup are
>>>>very technical, we need to develop a standard method of testing vario=
us new
>>>>modes under varying conditions using Moe Wheatley=92s, AE4JY, PathSim.
>>>>
>>>>Here is my suggestion.
>>>>
>>>>1) Create/develop a standard file of at least 400 words (5 characters=
one space
>>>>per word, 6 bytes =852.4KBPs).
>>>>
>>>>2) Generate this file in the mode to be tested and store it electroni=
cally on a
>>>>computer hard drive, CD or other magnetic storage media.
>>>>
>>>>3) =93Play=94 this file through the AE4JY=92s PathSim application at =
the following HF
>>>>Simulation parameters:
>>>>
>>>>
>>>>
>>>> CCIR 520-2 Conditions SRN (in dB)
>>>> Good Conditions +10 +5 0 -5
>>>> Moderate Conditions +10 +5 0 -5
>>>> Poor Conditions +10 +5 0 -5
>>>> Flutter fading +10 +5 0 -5
>>>> Low-latitude quite +10 +5 0 -5
>>>> Low-latitude disturbed +10 +5 0 -5
>>>> Mid-latitude quite +10 +5 0 -5
>>>> Mid-latitude disturbed +10 +5 0 -5
>>>> High-latitude quite +10 +5 0 -5
>>>> High-latitude disturbed +10 +5 0 -5
>>>>
>>>>4) Record output or =93play=94 it through the mode detector and captu=
re the output.
>>>>
>>>>
>>>>5) With software techniques to manually determine the throughput at e=
ach signal
>>>>condition.
>>>>
>>>>6) Document the results and provide the results to interested parties.
>>>>
>>>>I realize that this is just a rough draft of a testing process but t=
hink its is
>>>>within the capability of a number of list members and the results mig=
ht be VERT
>>>>INTERESTING.
>>>>
>>>>You comments solicited.
>>>>
>>>>Thanks & 73,
>>>>
>>>>Walt/K5YFW
>>>>
>>>>
>>>>
>>>>
>>>>
>>>><< Try MT63 on 80m - great fun!>>
>>>>
>>>>- The MT63 Reflector -
>>>> MT63@egroups.com
>>>>
>>>>(To unsubscribe. send email to
>>>>MT63-unsubscribe@onelist.com)
>>>>
>>>>Yahoo! Groups Links
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> =20
>>>>
>>>> =20
>>>>
>>>
>>><< Try MT63 on 80m - great fun!>>
>>>
>>>- The MT63 Reflector -
>>> MT63@egroups.com
>>>
>>>(To unsubscribe. send email to
>>>MT63-unsubscribe@onelist.com)
>>>
>>>Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>=20
>>>
>>> =20
>>>
>
>
>
> =20
>
------------------------ Yahoo! Groups Sponsor --------------------~-->=20
Over 1 billion served! The most music videos on the web.
Click to Watch now!
http://us.click.yahoo.com/xmKGzA/IARHAA/kkyPAA/CPMolB/TM
--------------------------------------------------------------------~->=20
<< Try MT63 on 80m - great fun!>>
- The MT63 Reflector -
MT63@egroups.com
(To unsubscribe. send email to
MT63-unsubscribe@onelist.com)
=20
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/MT63/
<*> To unsubscribe from this group, send an email to:
MT63-unsubscribe@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
=20
Read previous mail | Read next mail
| |
