Call Search
     

New to Ham Radio?
My Profile

Community
Articles
Forums
News
Reviews
Friends Remembered
Strays
Survey Question

Operating
Contesting
DX Cluster Spots
Propagation

Resources
Calendar
Classifieds
Ham Exams
Ham Links
List Archives
News Articles
Product Reviews
QSL Managers

Site Info
eHam Help (FAQ)
Support the site
The eHam Team
Advertising Info
Vision Statement
About eHam.net

   Home   Help Search  
Pages: [1]   Go Down
  Print  
Author Topic: How Do I Program A CW Keyer With Memory  (Read 1947 times)
TANAKASAN
Member

Posts: 933




Ignore
« on: May 27, 2012, 01:22:27 AM »

After years away from the industry I'm learning how to program again and my first project is a CW keyer. I know that these are commercially available but stick with me, OK? I've managed to generate correctly spaced dots, spaces and dashes but the CW memories feature has me stumped. Recording the dots and dashes are easy but it's the spaces that are the problem:

1) How do you store the spaces in memory when it could be a gap between elements, a word gap or the end of sending?

2) How do you store a series of CW messages in memory when they can be of variable length, from a long CQ to a quick contest exchange of callsigns and 5NN?

All clues welcome.

Tanakasan
Logged
PA0BLAH
Member

Posts: 0




Ignore
« Reply #1 on: May 27, 2012, 06:10:55 AM »

When you actually can't formulate a question all right, you can't expect that you understand the answer.

Because Morse code is variable length, you need a delimiter.
Put a character in a byte . A dash is a 1 and a dot is a zero, and the delimiter is a 1
So A will be 0110 0000 and Q will be 1101 1000.

Program a Morse character generator that shifts the code to the left via the carry, unless the byte is 1000 0000 then it is finished.
When the result is a one a dash is to be produced, when the result is a 0 a dot is to be produced.

When a dit is required switch on during the selected dit time and switch off during the selected dittime.
When a dash is required switch on during three selected dit times and off during one selected dit time.
When the byte is 1000 0000 hence only the length delimiter is left over , sent 2 additional off dits for the character space.

When the next character is a word space, ( ASCII hex 20) sent 4 additional dits off.

So save your messages in ASCII, and translate them according to this algorithm. An ASCII space 0x20 is the automatically implemented as 4 extra dit spaces above the already realised character space.

Best thing is not to ask everything that you not immediately know, but to use your brains to generate this or any other valid solution to your question.

Bob
« Last Edit: May 27, 2012, 06:19:30 AM by PA0BLAH » Logged
K8AXW
Member

Posts: 3902




Ignore
« Reply #2 on: May 28, 2012, 08:50:23 AM »

PA0BLAH:  I read your various replies here on eHam.com and believe that you're a very knowledgeable guy. 

However, and I mean no offense, after reading your snarky comments to TANAKASAN and others here, I think you need a short course in diplomacy.

People who post here have questions.  If you wish to help, fine.  If not, fine.  But to be rude because someone asks a question improperly, or uses the wrong syntax or even incorrect spelling isn't called for.

Logged
PA0BLAH
Member

Posts: 0




Ignore
« Reply #3 on: May 28, 2012, 12:52:55 PM »



People who post here have questions.  If you wish to help, fine.  If not, fine.  But to be rude because someone asks a question improperly, or uses the wrong syntax or even incorrect spelling isn't called for.



There is a Dutch proverb, that sounds (litererally translated):
 Each birdie whistles (sings)  such as its nozzle is.

So there is a choice between the answer the way I formulate it and no answer. Nothing else.
When the question poster prefers "no answer" it is his choice, because he doesn't have to read my reply.

Bob
Logged
AA4PB
Member

Posts: 12899




Ignore
« Reply #4 on: May 28, 2012, 04:53:50 PM »

Another way to do it that may be easier to code, if you have plenty of memory, is to assign an ascii character for dot, another for dash, and another for space, and perhaps one for word space. Then store the character representations in memory. Depending on the processor and language you may find it easier to read and write ascii characters than to attempt to do it bit by bit.

You could also store it as the actual ascii characters and convert to/from Morse. You'd have to add characters for the prosigns to the ascii table. That opens up the potential to use a keyboard for memory entry which is easier to use (in my opinion) than trying to get the processor to copy the user's hand sending.

Logged
VA7CPC
Member

Posts: 2393




Ignore
« Reply #5 on: May 28, 2012, 06:35:14 PM »

AA4PB has hit on an important point:

. . . Choosing _how to represent Morse code_ in the memory is an important design decision.

In my Yaesu FT-450 (for example), one stores text into memory locations by picking characters from a predefined list (A-Z, 0-9, some punctuation (which includes prosigns like "=", and blank).  I'm sure that the "memory reader" code just uses a character-to-Morse table to generate the dits, dahs, and spaces when it sends the contents of a memory location.

That's very different from PA0BLAH's assumption that the dits and dahs were stored individually, and that delimiters were needed.   

I don't know how the K1EL WinKeyer handles memory storage.  It has some capabilities (like changing speed in the middle of a message) that are beyond what the FT-450 can do.  So its storage scheme is certainly more complex.  Since it "reads" memory input from the paddle (if desired), it also must include a "paddle reader" function -- a primitive CW decoder!

Personally (as a high-level-language programmer), I think _any_ attempt to work at the PIC level is praiseworthy.

          Charles
Logged
PA0BLAH
Member

Posts: 0




Ignore
« Reply #6 on: May 29, 2012, 01:36:33 AM »

AA4PB has hit on an important point:

. . . Choosing _how to represent Morse code_ in the memory is an important design decision.

[..]

That's very different from PA0BLAH's assumption that the dits and dahs were stored individually, and that delimiters were needed.  
[..]
 Since it "reads" memory input from the paddle (if desired), it also must include a "paddle reader" function -- a primitive CW decoder!


          Charles


That is not very different, but exactly what I wrote:
 
Quote
So save your messages in ASCII, and translate them according to this algorithm. An ASCII space 0x20 is the automatically implemented as 4 extra dit spaces above the already realised character space.

You need a look up table for translation ASCII in Morse code the way I described for A and Q with a delimiter. Table starts at
index 0x21 . One byte per entry. The prosign [HH] falls out, but is generally transmitted as [IMI] or I I.  Furthermore you don't need [HH] in messages stored in the memory of a keyer. And the ASCII lower characters in the stored text , possibly present when you did not enter the text in memory with paddles, are first converted to upper case by substacting 0x20

And yes, when you want to enter text via your paddle's  you need a translation Morse to ASCII in the keyer, that has the advantage that you can watch your transmitted text, watch the numbers 6 instead of B or even D transmitted, the 5 instead of the H, the : instead of the 8. And finally the enormous bunch of character spaces 0x20 you generated by too wide character spaces.

When you want to have an impression of your own sending, in the past there were papertapes, with a ruler you could measure the length of the elements.

Nowadays you can use a recording with your computer in the form of a wav file, look with Wave Studio (Soundblaster) or Audacy (a freeware audio editor) .You even don't need a ruler because the cursor is accompanied by the time in ms.
(The ISO international standardized  abbreviation for millisecond is ms and not msec)  

« Last Edit: May 29, 2012, 04:06:04 AM by PA0BLAH » Logged
TANAKASAN
Member

Posts: 933




Ignore
« Reply #7 on: June 01, 2012, 12:37:14 AM »

Thanks for all the ideas so far. Right now I'm storing the dots and dashes as two separate bits and using the following table

00     Element space
01     Dot
10     Dash
11     Word space

This means that I can do the job in two bits rather than eight.

As for timing the spaces I had one idea last night to use the internal counters in the PIC. With both paddles released the counter starts counting up then eventually one of three things happens

Paddle closes after a short period, code 00 (Element space) loaded into memory
Paddle closes after a long period, code 11 (Word space) loaded into memory
No closure and counter overflows, PIC terminates storage of message

Getting the length of these periods right will be an interesting challenge but further ideas are of course welcome.

Tanakasan

Logged
Pages: [1]   Go Up
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!