Home |
Search |
Today's Posts |
#35
|
|||
|
|||
Len:
Right now I am running a 3.8Ghz processor clock with a 466Mhz memory clock on a bus capable of 266Mhz. The fastest keyer would leave the hardware/software killing time to await his next di or dah... The purpose of the "error file" is to catch new abreviations so they can be added to the table, let them come up with as many variations as they possibly can, in the end the reader is only made stronger... John On Thu, 04 Aug 2005 12:01:04 -0700, LenAnderson wrote: From: John Smith on Aug 3, 10:51 pm Len: Yep, that is one way alright, and produces good results, there are others, some better. Adaptive learning by the program is the key, and the program must learn what the senders' length of a di to a dah is, and the breath of the width he is spanning of each the di and the dah. The amateur abbreviations are in a table, and the dictionary from a spell checker can be borrowed to check decoded morse words against which are not abbreviations. There's no need to use a table of abbreviation...those can vary from time to time and operator to operator. The MAJOR problem is determining the "dit rate"...once that is done, the "dah" can be separated, also the inter-character spacing. You are right, a high speed machine affords you time to do abundant error checking--and here is where you gain close to 100% accuracy from, final fall back is the ear and the mind, to correct any mistakes the program cannot, yet, handle... Those who've never gotten far INTO computer programming will NOT fully understand how blazing fast a 2 GHz clock PC really is! My platform isn't top-of-the-line at 2 GHz clock and 100 MHz RAM access...but it can almost blow the mind on how fast it can handle anything in the Win32 family...I am getting slowly into that through PowerBasic Compiler, calling the canned Win32 routines directly. Back in '92 I shifted over to a moderate PC with a 20 MHz clock and 1 MHz RAM access rate...and was checking various forms of complex number calculation combinations to handle LARGE two- dimensional arrays. Had those runing at tens of thousands of random-quantity repetitions in order to get the fastest. That was for a ported-over circuit analysis program from RCA in the 70s (which I had helped improve - along with others in Central Engineering - then). In the 1970s, any mainframe with a 10 MHz clock and 1 MHz RAM access was considered "top of the line." :-) I dug out the same PC time test routines and ran them on THIS platform and the runs were just an eyeblink long. :-) In order to actually time them, I had to increase the number of iterations a hundred times (from about 10K) in order to see some semblance of actually working hard! All words which do not match the table of abbreviations or the dictionary have a copy of that word thrown into an error file, along with di's represented by periods and dah's represented by underscores or hyphens, of the word thought to be an error. This error file can be studied later and the program "tweaked" to handle such errors in the future. I disagree. The first task is to ADAPT to the going rate. That requires only a temporary memory (but a large one at that since one dimension MUST be time) to set the approximate received rate. When rate is approximated, there can be a built-in weighting on time duration to determine dit from dah. Simple conditional yes- no on duration but the trick seems to be arriving at a good decision point in time. "Abbreviations" tables aren't needed. In fact, from seeing such a program working (and being able to look at the flow diagrams of the routines...source was in C++ but flow diagrams were in standard box-diamond form...the common abbreviations and Q codes could be left as they were in ASCII on the screen. Since morse operators tended to have a great variation in inter-character and inter-word spacing, those spaces were just left in the screen display and the human reader could do the final "adaptation" on what the spaces meant (or didn't mean). However, what interests me most is your knowledge on the subject, you most certainly have a good grasp of the logic necessary to begin to put one together. In 1970 (at an RCA division in Van Nuys, CA) I got a chance to do programmed calculations on an HP 9100 desk calculator...did some statistics runs on aircraft collision avoidance estimates, part of a long-range R&D project at RCA devised by the late Jack Breckman (a genius type who could extemporaneously speak in ordered paragraphs). Found that programming and I got along very well and a "romance" of sorts happened, went full-flower with successful negotiations with bean counters to get corporate computer time (then horribly expensive). Got Dan McCracken's softcover on FORTRAN IV Programming to explain the program ordering (damn good book, Dan became President of the ACM for a time later), won a steak dinner bet with another on being able to make a running program and off it went to bigger, better things. The epiphany happened due to a supplier delay on some small inductors for a vital hardware delay line...could I use a "close, but not quite right" inductor which was plentiful? Did a simulation run for pulse shape on the corporate computer using the possible replacement, decided it was okay. When the replacement parts arrived, I quickly tack-soldered the delay line together, viewed the pulse shape though it and found the computer simulation waveform matched the real waveform EXACTLY! I was sold and a definite believer in accurate simulation ever since. Perhaps you have programmed and played with such yourself? Perhaps you have a relative or friend in the field? I never bothered with a "morse code reader" program. Wayyyyy TOO MANY OTHER kinds of calculations that would be of immense value. When my group at the RCA division was disbanded in '75, I had six programs in the Central Engineering software library and have had four other programs as Shareware back in times before the Internet went public. Those are all Freeware now, not that it matters much with Windows and other GUI-ey graphic screens being "what all want." :-) As a former voting member of the ACM, courtesy of cross-membership privilege of the IEEE, I've worked with/known a bunch of computer programmers. The kind that can DO THE WORK and DEMONSTRATE it without pointing to a bunch of framed/plaqued certificates on the wall. One of those was the guy I described...one who had the HOBBY of programming as well as doing it every day for a living. We were friends enough for him to let me look at all pages of his project notebook...and myself letting him use my Icom receiver as a morse signal source. He thought it was a fun program to do, while I thought morsemanship wasn't worth bothering about...but, it was a fascinating challenge to mechanize and to make work. His development platform was rather faster than my 20 MHz clock thing and - as it was written then without final optimization - wouldn't work with high rates of the speed-freak hams (I knew of two, one in Frisco, the other near San Diego, both retired and busy beeping each other most every day then). Right now I can order a Microchip PIC from DigiKey running at a 50 MHz clock, get a couple large EPROMs to hold the source code (if ported) and it would work fine, I'm sure. PIC's RISC instruction set is NOT compatible with 80x86 instruction set and takes a lot of translation. Thank you, I'll take canned PIC programs, use those and be done with it. I do NOT have ANY sort of decoder for morse, TTY, commercial SSB TTY tones, any of the TORs in-house. Not my cuppa either. The 'TOR peripheral boxes are cheap enough that I could buy one and use it if the interest struck. No problem. Someone else did the design, debug, engineering and I respect that; no sense in re-inventing wheels unless it's to make them more rounded, smoother, etc. :-) Note: Watch for Jimmie Noserve, the Nun of the Above, to pick up on that last sentence and use it later in chiding postings agin' me...it might be weeks before he do dat, but he gots a memory like an effluent and will issue it later. Predictable. NSA BSA |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Forum | |||
BBC Says Morse Code Still Alive and Well In UK | Policy | |||
Morse Code: One Wonders... and Begins to Think ! [ -- --- .-. ... . / -.-. --- -.. . ] | Shortwave | |||
Response to "21st Century" Part One (Code Test) | Policy | |||
Some comments on the NCVEC petition | Policy | |||
NCVEC NPRM for elimination of horse and buggy morse code requirement. | Policy |