Searching \ for 'Morse Decoder' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=morse+decoder
Search entire site for: 'Morse Decoder'.

Truncated match.
PICList Thread
'Morse decoder'
1998\11\02@145837 by Les

flavicon
picon face
Thanks for your response about the morse decoder, but what I really want to
experiment with is something like the Vellamen kit from maplins. A pic with
an LCD display.There was a diagram for one with the PICICE II that I have
bought recently but to get the code you have to buy a preprogrammed chip
from them (Why put the bloody diagram in if you dont have the code to
emulate on there emulator?). On the subject of this emulator originally from
Leading edge technology and sold by crownhill it is NOT recommended, the
software looks as if has been written as an afterthought to the hardware,
amateurish and Tacky and the documentation is non existant, you get better
instructions on the side of a tin of soup. I wish I had added the extra
money and bought an emulator from Microchip. We live and learn!!!!

                               Regards
                                           Les

1998\11\03@191032 by bejones

flavicon
face
Life is sometimes curious. Last weekend I spent most of the
weekend designing a protoboard and software to use as a base for -
yes you've guessed it a Morse Decoder! The stripboard prototype
has a 4*20 LCD (cos I got one very cheap) driven by a 74164 and 3
16F84 pins and a 24LC65 using 2 more of the pins. All the 3 wire-
LCD software works OK and all the I2C to the 24LC65 now works.

Basic idea is to detect interrupt on PORTB and try to figure out
dot, dash (or space equivalents) and then use the 24LC65 to hold
both menu options and a sparse lookup table for the Morse. That
way pretty much all the PIC processing can go into figuring out
dot/dash.

I had planned initially just to attach a key to PORTB for testing -
then play around with an electret mike passing thru some
bandpass filter to a 567 tone decoder - but since my electronic
skills are very poor I might need some help here!

Anyone worked on any morse decoding algorithms wants to share
ideas then fine - pls let me know - probably best to my reader
direct and if there is  interest I'll summarize here later

Brian
Brian Jones
Technical Planner
Java Technology Centre
IBM Hursley

1998\11\04@143140 by John Payson

flavicon
face
|Anyone worked on any morse decoding algorithms wants to share
|ideas then fine - pls let me know - probably best to my reader
|direct and if there is  interest I'll summarize here later

One story I read somewhere, but I'd like to find a real and definitive
source for it, was that the original purpose of the telegraph was in
fact to produce marks on paper (the paper being moved at a constant
speed while the solenoid controlled a pen).  Tapping the pen against the
paper briefly would produce a dot while holding it would produce a dash.
The idea, then, was that the recipient of a message, following its receipt,
would then proceed to decode the dots and dashes on the paper into letters,
numbers, and other symbols.

The idea of a telegraph simply operating a noisemaker (and having the message
recipient listen for the message as it was being sent) came later, after some
people (including, interestingly enough, Andrew Carnegie) discovered that they
didn't have to look at the paper to know what message had just been sent.

Returning to the real of PICs, there may be some advantages to storing the act-
ual sequence of dots and dashes, rather than trying to grab the information "on
the fly"; while the dot/dash ratio is supposed to be about 3:1, leaving some
substantial room for error, I would expect that there are probably some ham-hand
ed
operators whose coding is not very consistent.  If you have the ability to compa
re
the length of marks and spaces to those that come after as well as those that ca
me
before, you may be better able to divide the marks into the two proper categorie
s
and the spaces into three.

1998\11\04@152232 by Gavin Jackson

flavicon
face
The first thing that comes to mind is to decode the
dot dash dash dot into 0110 with a '1' representing
dash and a '0' representing the dot. Then store a
table in the PIC and do a simple compare through
the table until a match is found. The only problem
I see with this method is trying to tell the difference
between a J ( . - - - ) and a 2 ( . . - - - ) which would be
0111 and 00111 respectively.

Maybe this gives you some other ideas.

Regards

Gavin
--------------------------
spam_OUTvulcanTakeThisOuTspamihug.co.nz
ICQ# 18675389
www.geocities.com/TheTropics/Cabana/2625
--------------------------

Sent:   Wednesday, 04, November, 1998 01:08 PM
To:     .....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU
Subject:        Re: Morse Decoder

Life is sometimes curious. Last weekend I spent most of the
weekend designing a protoboard and software to use as a base for -
yes you've guessed it a Morse Decoder! The stripboard prototype
has a 4*20 LCD (cos I got one very cheap) driven by a 74164 and 3
16F84 pins and a 24LC65 using 2 more of the pins. All the 3 wire-
LCD software works OK and all the I2C to the 24LC65 now works.

Basic idea is to detect interrupt on PORTB and try to figure out
dot, dash (or space equivalents) and then use the 24LC65 to hold
both menu options and a sparse lookup table for the Morse. That
way pretty much all the PIC processing can go into figuring out
dot/dash.

I had planned initially just to attach a key to PORTB for testing -
then play around with an electret mike passing thru some
bandpass filter to a 567 tone decoder - but since my electronic
skills are very poor I might need some help here!

Anyone worked on any morse decoding algorithms wants to share
ideas then fine - pls let me know - probably best to my reader
direct and if there is  interest I'll summarize here later

Brian
Brian Jones
Technical Planner
Java Technology Centre
IBM Hursley

1998\11\04@161639 by Sean Breheny

face picon face
At 01:32 PM 11/4/98 -0600, you wrote:
>
>Returning to the real of PICs, there may be some advantages to storing the
act-
>ual sequence of dots and dashes, rather than trying to grab the
information "on
>the fly"; while the dot/dash ratio is supposed to be about 3:1, leaving some
>substantial room for error, I would expect that there are probably some
ham-handed
>operators whose coding is not very consistent.  If you have the ability to
compare
>the length of marks and spaces to those that come after as well as those
that came
>before, you may be better able to divide the marks into the two proper
categories
>and the spaces into three.
>

Hi John,

I think that this would be a good idea, too, except that many such
applications require that the user be able to see the output "on the fly".
Also, I don't think that it is necessary to do what you propose in many
cases. I wrote a routine in BASIC for my PC which does it pretty well and
it just adjusts the max/min dot/dash times as it goes, depending on what is
being received.

Sean

+-------------------------------+
| Sean Breheny                  |
| Amateur Radio Callsign: KA3YXM|
| Electrical Engineering Student|
+-------------------------------+
Save lives, please look at http://www.all.org
Personal page: http://www.people.cornell.edu/pages/shb7
shb7spamKILLspamcornell.edu  Phone(USA): (607) 253-0315 ICQ #: 3329174

1998\11\05@034902 by Mark Willis

flavicon
face
John Payson wrote:
> One story I read somewhere, but I'd like to find a real and definitive
> source for it, was that the original purpose of the telegraph was in
> fact to produce marks on paper (the paper being moved at a constant
> speed while the solenoid controlled a pen).  Tapping the pen against the
> paper briefly would produce a dot while holding it would produce a dash.
> The idea, then, was that the recipient of a message, following its receipt,
> would then proceed to decode the dots and dashes on the paper into letters,
> numbers, and other symbols.

 Hmmm, IIRC originally I thought Edison was a telegraph operator
(before he became an inventor) & he worked on some kind of automatic
telegraph forwarding thingies as his first inventions (as telegraphs had
SHORT! ranges back then? like 5 miles?) - those used paper or something
like that, to repeat the signal?  But I thought it wasn't pen-based,
rather burn marks on paper somehow, as ball point pens didn't exist then
<G>  Fountain pens might not work well here...

 1870's/1880's patents by edison, maybe?  (I'm offline just now.)

 Mark, .....mwillisKILLspamspam.....Nwlink.com

1998\11\05@081626 by Nuno Pedrosa

flavicon
face
I am a scout, and was thinking of this recently, to use in my Palm 3.

In morse, there are 3 symbols: dot, dash and space.

You can't translate a morse message like:

......-...-..---

Without pauses, you will have many possible combinations!
It could be possible to generate the most probable message, but
it would be very difficult to get the exact one!

.... . .-.. .-.. ---

Having the symbols separated and encoded like Gavin said,
why not just implementing a 2-way table?

To detect the symbols, we could have 3 configurable times:

- dot time
- hash time
- space time

Use a TMR and a pin with interrupt on change. Measure the
value and the length of the value. Doesn't seem very hard,
but, then again, I'm just talking... 8)

By the way, for those who don't have a morse table handy,
I said

h e l l o

Comments, anyone?

Nuno.


Gavin Jackson wrote:
{Quote hidden}

--
----  ~~~~~~  --------  Nuno Filipe Freitas Pedrosa
--  ~~~~     ~~  -----  SIEMENS S.A. Portugal       TEL: +351 1 4242454
-  ~~~~       ~~  ----  EraseMENuno.Pedrosaspam_OUTspamTakeThisOuToen.siemens.de
-  ~~~~       ~~  ----  "Smile, and tomorrow will be a better day!"
=======================================================================

1998\11\05@105738 by Harrison Cooper

flavicon
face
you need to be able to adjust for the WPM and CPM.  I have a morse
machine that this can be adjusted on.  A long time ago, say, some 20
years ago, one of the mags had a project to do this, but used all
discrets.  I had copied it, but it is long gone now.

{Quote hidden}

1998\11\05@110958 by Peter L. Peres

picon face
On Thu, 5 Nov 1998, Gavin Jackson wrote:

> The first thing that comes to mind is to decode the
> dot dash dash dot into 0110 with a '1' representing
> dash and a '0' representing the dot. Then store a
> table in the PIC and do a simple compare through
> the table until a match is found. The only problem
> I see with this method is trying to tell the difference
> between a J ( . - - - ) and a 2 ( . . - - - ) which would be
> 0111 and 00111 respectively.

The usual way to encode decoded morse for id purposes is a 4-way code,
with 2 bits per symbol. That's like:

00 - dot
01 - dash
10 - long space
11 - error (neither of above) or end symbol.

Then you can pack these 4 per byte and life becomes easier. The end symbol
is used in the table and in the receiver buffer, in the latter it having
the meaning of 'error'. There are other schemes too. Note that you can
encode strings like this in tables. This is used for beacons, ids etc.

Of course you can compress the symbol recognition table by dropping the
MSB in each symbol using the code outlined above.

hope this helps,

Peter

1998\11\05@113918 by Dave VanHorn

flavicon
face
> > To detect the symbols, we could have 3 configurable times:
> >
> >  - dot time
> >  - hash time  (I think you meant Dash time?)
> >  - space time

There is also an inter-char time, which is supposed to be three "dots"
worth.
That varies a lot in hand-keyed code.

> > Use a TMR and a pin with interrupt on change. Measure the
> > value and the length of the value. Doesn't seem very hard,
> > but, then again, I'm just talking... 8)

This has a lot of similarities to reading barcodes.
Reading machine-transmitted morse should be pretty easy, and that's
where I'd start. You have a variable length code (1-N elements) where
each element is separated by a short pause. There is a longer pause
between chars. (3 dot times is the spec)

Reading hand-keyed morse is more interesting. You could keep recent
timings in memory, and extract dot, dash, and inter-char timing from
them, updating as you go.

The good news is that the occasional substitution or missed element
isn't a huge problem. The end user can still read "SAPPY BIRHDAY" and
get the meaning.
(H > S by dropping a dot, and somehow we missed the - which is a T)

Also, hams tend to send morse in rather abbreviated text like this:

GD EVN OM HNDL HR IS DAVE LOC IS MUNCIE IN USA
WTHR HR IS BAD ICE N SNO

There are also "prosigns" to consider, where two chars are slid into
each other, like AR: *-*-* and they have special meanings.

If you're going to go to all that trouble, you might as well get your
ham licence. By the time you get this working, you'll be able to receive
5wpm and qualify for the tech plus licence.

1998\11\05@115310 by Nuno Pedrosa

flavicon
face
Ops! I forgot the little detail of finding a morse code coded with 0 and
1 in
such a table...

Well, if the conversion is made "on the fly", it seems rather easy. All
we need is
the length of the morse symbol. And that's just a counter. Comparison
will have to
be more complicated, since the key to find a letter will consist of the
symbol and
the length...
We could have several tables like this:
Length 1: E T
Length 2: A I M N
Length 3: D G K O R S U W
Length 4: B C F H J L P Q V X Y Z
Length 5: 0 1 2 3 4 5 6 7 8 9

Or maybe someone can come up with a logical operation to combine the
length and the code, producing an unique key...

Nuno.

Nuno Pedrosa wrote:
{Quote hidden}

--
----  ~~~~~~  --------  Nuno Filipe Freitas Pedrosa
--  ~~~~     ~~  -----  SIEMENS S.A. Portugal       TEL: +351 1 4242454
-  ~~~~       ~~  ----  spamBeGoneNuno.PedrosaspamBeGonespamoen.siemens.de
-  ~~~~       ~~  ----  "Smile, and tomorrow will be a better day!"
=======================================================================

1998\11\05@115743 by Peter L. Peres

picon face
On Thu, 5 Nov 1998, Mark Willis wrote:

> like that, to repeat the signal?  But I thought it wasn't pen-based,
> rather burn marks on paper somehow, as ball point pens didn't exist then
> <G>  Fountain pens might not work well here...

Last time I say a decent drawing of an Edison receiver it used an inked
roller and a solenoid to make it touch the paper. There was an ink-soaked
felt (?) roller in permanent contact with the writing roller. I would not
like to have to use such a thing without gloves.

Peter

1998\11\05@121822 by Harold Hallikainen

picon face
John Payson wrote:
> One story I read somewhere, but I'd like to find a real and definitive
> source for it, was that the original purpose of the telegraph was in
> fact to produce marks on paper (the paper being moved at a constant
> speed while the solenoid controlled a pen).  Tapping the pen against
>the paper briefly would produce a dot while holding it would produce a
>dash.  The idea, then, was that the recipient of a message, following
its
>receipt, would then proceed to decode the dots and dashes on the paper
into
>letters,  numbers, and other symbols.
>

       I believe Morse's original telegraph did indeed mark moving
paper.  It made noise as it did it.  Experienced telegraphers eventually
could read a message from across the room by hearing the clicks and not
looking at the paper.  Getting rid of the paper mechanism vastly
simplified the telegraph.

Harold



Harold Hallikainen
TakeThisOuTharoldEraseMEspamspam_OUThallikainen.com
Hallikainen & Friends, Inc.
See the FCC Rules at http://hallikainen.com/FccRules and comments filed
in LPFM proceeding at http://hallikainen.com/lpfm

___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]

1998\11\05@150918 by Harold Hallikainen

picon face
On Thu, 5 Nov 1998 18:03:57 +0000 "Peter L. Peres" <RemoveMEplpspamTakeThisOuTACTCOM.CO.IL>
writes:
>On Thu, 5 Nov 1998, Gavin Jackson wrote:
>
>> The first thing that comes to mind is to decode the
>> dot dash dash dot into 0110 with a '1' representing
>> dash and a '0' representing the dot. Then store a
>> table in the PIC and do a simple compare through
>> the table until a match is found. The only problem
>> I see with this method is trying to tell the difference
>> between a J ( . - - - ) and a 2 ( . . - - - ) which would be
>> 0111 and 00111 respectively.
>
>The usual way to encode decoded morse for id purposes is a 4-way code,
>with 2 bits per symbol. That's like:
>
>00 - dot
>01 - dash
>10 - long space
>11 - error (neither of above) or end symbol.
>

       I did a Morse ENCODER years ago on a motorola 6802.  ASCII codes
indexed into a table where each Morse character was represented by a
byte.  The 5 least significant bits were 0 for dit and 1 for dah.  The 3
most significant bits indicated how many of the lsb's to use.  This
allowed the use of 5 dits and/or dahs per character, which handles the
alphabet, numbers, and most punctuation (but not stuff like End Of
Transmission ...-.-).  I wrote that 10 or 15 years ago.  A few hundred
units still out there running...


Harold



Harold Hallikainen
haroldEraseMEspam.....hallikainen.com
Hallikainen & Friends, Inc.
See the FCC Rules at http://hallikainen.com/FccRules and comments filed
in LPFM proceeding at http://hallikainen.com/lpfm

___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]

1998\11\06@102939 by bejones

flavicon
face
OK
      here's what I was planning to do

Set up one B pin as interrupt on change and on each interrupt read
prescaled TMR0 (+ overflow so its 16 bits) and note rising/falling
edge of B pin.

If TMR0 very low or very large then either its key debounce or a
long silence (or key do) - ignore in both cases  (even at 30wpm a .
is .04 seconds long so anything below .08 is noise at least for
morse I want to listen to and above 1 second or so is also noise
except for VLFers breaking distance records!!)

If not, figure out length of pulse -1 for dot or inter dot-dash space, 3
for dash or inter char space, 7 for inter word space.  This is the
hard bit at least will need to keep some history to recalibrate
continuously (maybe with bounds to introduce some hysterisis so
not always recalbrating)

Once we think we've got a whole char build up a byte with most sig
byte as marker to say morse starts next - eg R = .-. = 00001010
(ie 0000 pad 1 to say next bits count 0=., 1=-, 0=.). Use the
resulting value as lookup in sparse table on 24LC65 to return ASCII
value. If there as enough code memory then we could check lookup
returned a valid ASCII char, if not and we had store some degree of
confidence re each . or - then could try next most likely combo

Key thing is to get all the tables and memory off the PIC to
maximise memory for as many smarts in determining char as
possible

Still oodles of problems - many hams send DE (from in ham
parlance) as _..,. where the , is about half a normal inter char
space and other such trickery. Many rattle there callsigns out
calling CQ but slow down when sending detail.

I think this will all work - now just need to figure out how to do that
hard bit in the middle :-)

Hardware should be easy once we've got this working with a direct
attached key - using a 567 tone decoder and audio filter should
work I think.

Brian
Brian Jones
Technical Planner
Java Technology Centre
IBM Hursley

1998\11\06@140614 by John Payson

flavicon
face
|We could have several tables like this:
|Length 1: E T
|Length 2: A I M N
|Length 3: D G K O R S U W
|Length 4: B C F H J L P Q V X Y Z
|Length 5: 0 1 2 3 4 5 6 7 8 9

A simpler approach, if you use "1" for dash and "0" for dot is to
add a single "1" before or after the received symbol and pad the
rest with zeroes.  Thus:

E : 00000010   .
T : 00000011   _
I : 00000100   ..
A : 00000101   ._
N : 00000110   _.
M : 00000111   __
S : 00001000   ...
O : 00001111   ___

etc.  This will allow most (all?) symbols and prosigns other than the
standard distress call (...___...) to be handled with a single byte
compare (the number of symbols of length LESS THAN eight, counting the
null symbol, is equal to the number of symbols of length eight)

1998\11\06@144130 by William M. Smithers

flavicon
face
On Fri, 6 Nov 1998, John Payson wrote:

{Quote hidden}

I did this *many* years ago with an EPROM-based wide path state machine
that latched the data back into the addresses.  Dit's and dah's
would be fed in as they occurred, which would drive the state
machine to a successively narrower solution, until the ASCII would
pop out the first 8 data bits.  A detected inter-character space
would reset the address latch and load the output data latch.

No CPU at all - worked great.  I don't recall how many EPROMS
it took to create the state machine...but it doesn't matter,
because I spent so much time building that thing so that
I could cheat on the morse code portion of my Ham license exam
that I didn't study and flunked the written part...

-Will

1998\11\06@192249 by Mark A Moss

picon face
On Thu, 5 Nov 1998 13:05:53 +0000 Nuno Pedrosa
<EraseMENuno.PedrosaspamOEN.SIEMENS.DE> writes:
>.... . .-.. .-.. ---
>
>By the way, for those who don't have a morse table handy,
>I said
>
>h e l l o
- .- -... .-.. . --..--   ..   -.. --- -. -   -. . . --.   -. ---
- .- -... .-.. . .-...


Mark Moss
Amateur Radio Operator, Technician, and General Tinkerer

___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]

1998\11\09@045053 by Dr. Imre Bartfai

flavicon
face
Hi all,

just an idea I use...

I have always problem to interface my PIC applications with the
developer/user. I have not enough pins, I dont want to connect a PC etc.
I use now morse codes as a solution. I need only one output pin. I wrote a
small routine, it gets a character/digit as an input parameter and it
sends it acoustic to the environment. I set up a table. Every entry has 8
bits: the first 3 is the length of the code, the remaining 5 is the morse
code of that letter/digit (sorry, no comma, period or whatsoever). In the
code part 1 means 'dah', 0 means 'dit'. The former has 300 msec, the
latter is 100 msec in duration. To understand and interpret this code is
far more simple than the same using a LED. The speed is slow enough to be
understood by an unexperienced operator also (I'm sorry, but I did not
calculated the WPM...).

Maybe another PICler can use also this idea.

Imre

1998\11\09@055708 by Nuno Pedrosa

flavicon
face
Lucky you! 8)

So, you said:

"table ? I dont neeg no table ?"

The ? are the symbols which do not exist in my table. I only have the
alfabet and digits. 8)
I'm no Radio Operator... Just a curious.

Could you tell me what those symbols mean?

Thank you.
Nuno.

PS: BTW, is that a typo in your message ("neeg") or is my table wrong?
8)

Mark A Moss wrote:
{Quote hidden}

--
----  ~~~~~~~  -------  Nuno Filipe Freitas Pedrosa
--  ~~~~     ~~  -----  SIEMENS S.A. Portugal       TEL: +351 1 4242454
-  ~~~~       ~~  ----  RemoveMENuno.Pedrosaspam_OUTspamKILLspamoen.siemens.de
-  ~~~~       ~~  ----  "If it doesn't fit the hole, whack harder!"
=======================================================================

1998\11\09@093238 by Joao Batista

flavicon
face
part 0 75 bytes

Attachment converted: wonderland:morse_decoder.zip (pZIP/pZIP) (0001CEA5)

1998\11\19@151003 by Harold Hallikainen

picon face
On Thu, 5 Nov 1998 18:03:57 +0000 "Peter L. Peres" <RemoveMEplpTakeThisOuTspamspamACTCOM.CO.IL>
writes:
>On Thu, 5 Nov 1998, Gavin Jackson wrote:
>
>> The first thing that comes to mind is to decode the
>> dot dash dash dot into 0110 with a '1' representing
>> dash and a '0' representing the dot. Then store a
>> table in the PIC and do a simple compare through
>> the table until a match is found. The only problem
>> I see with this method is trying to tell the difference
>> between a J ( . - - - ) and a 2 ( . . - - - ) which would be
>> 0111 and 00111 respectively.
>
>The usual way to encode decoded morse for id purposes is a 4-way code,
>with 2 bits per symbol. That's like:
>
>00 - dot
>01 - dash
>10 - long space
>11 - error (neither of above) or end symbol.
>

       I did a Morse ENCODER years ago on a motorola 6802.  ASCII codes
indexed into a table where each Morse character was represented by a
byte.  The 5 least significant bits were 0 for dit and 1 for dah.  The 3
most significant bits indicated how many of the lsb's to use.  This
allowed the use of 5 dits and/or dahs per character, which handles the
alphabet, numbers, and most punctuation (but not stuff like End Of
Transmission ...-.-).  I wrote that 10 or 15 years ago.  A few hundred
units still out there running...


Harold



Harold Hallikainen
EraseMEharoldspamspamspamBeGonehallikainen.com
Hallikainen & Friends, Inc.
See the FCC Rules at http://hallikainen.com/FccRules and comments filed
in LPFM proceeding at http://hallikainen.com/lpfm

___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]

1998\11\20@074058 by Harold Hallikainen

picon face
John Payson wrote:
> One story I read somewhere, but I'd like to find a real and definitive
> source for it, was that the original purpose of the telegraph was in
> fact to produce marks on paper (the paper being moved at a constant
> speed while the solenoid controlled a pen).  Tapping the pen against
>the paper briefly would produce a dot while holding it would produce a
>dash.  The idea, then, was that the recipient of a message, following
its
>receipt, would then proceed to decode the dots and dashes on the paper
into
>letters,  numbers, and other symbols.
>

       I believe Morse's original telegraph did indeed mark moving
paper.  It made noise as it did it.  Experienced telegraphers eventually
could read a message from across the room by hearing the clicks and not
looking at the paper.  Getting rid of the paper mechanism vastly
simplified the telegraph.

Harold



Harold Hallikainen
RemoveMEharoldKILLspamspamhallikainen.com
Hallikainen & Friends, Inc.
See the FCC Rules at http://hallikainen.com/FccRules and comments filed
in LPFM proceeding at http://hallikainen.com/lpfm

___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]

1998\11\20@074114 by Peter L. Peres

picon face
On Thu, 5 Nov 1998, Mark Willis wrote:

> like that, to repeat the signal?  But I thought it wasn't pen-based,
> rather burn marks on paper somehow, as ball point pens didn't exist then
> <G>  Fountain pens might not work well here...

Last time I say a decent drawing of an Edison receiver it used an inked
roller and a solenoid to make it touch the paper. There was an ink-soaked
felt (?) roller in permanent contact with the writing roller. I would not
like to have to use such a thing without gloves.

Peter

1998\11\20@075534 by Nuno Pedrosa

flavicon
face
Ops! I forgot the little detail of finding a morse code coded with 0 and
1 in
such a table...

Well, if the conversion is made "on the fly", it seems rather easy. All
we need is
the length of the morse symbol. And that's just a counter. Comparison
will have to
be more complicated, since the key to find a letter will consist of the
symbol and
the length...
We could have several tables like this:
Length 1: E T
Length 2: A I M N
Length 3: D G K O R S U W
Length 4: B C F H J L P Q V X Y Z
Length 5: 0 1 2 3 4 5 6 7 8 9

Or maybe someone can come up with a logical operation to combine the
length and the code, producing an unique key...

Nuno.

Nuno Pedrosa wrote:
{Quote hidden}

--
----  ~~~~~~  --------  Nuno Filipe Freitas Pedrosa
--  ~~~~     ~~  -----  SIEMENS S.A. Portugal       TEL: +351 1 4242454
-  ~~~~       ~~  ----  spamBeGoneNuno.PedrosaSTOPspamspamEraseMEoen.siemens.de
-  ~~~~       ~~  ----  "Smile, and tomorrow will be a better day!"
=======================================================================

1998\11\20@075557 by Dave VanHorn

flavicon
face
> > To detect the symbols, we could have 3 configurable times:
> >
> >  - dot time
> >  - hash time  (I think you meant Dash time?)
> >  - space time

There is also an inter-char time, which is supposed to be three "dots"
worth.
That varies a lot in hand-keyed code.

> > Use a TMR and a pin with interrupt on change. Measure the
> > value and the length of the value. Doesn't seem very hard,
> > but, then again, I'm just talking... 8)

This has a lot of similarities to reading barcodes.
Reading machine-transmitted morse should be pretty easy, and that's
where I'd start. You have a variable length code (1-N elements) where
each element is separated by a short pause. There is a longer pause
between chars. (3 dot times is the spec)

Reading hand-keyed morse is more interesting. You could keep recent
timings in memory, and extract dot, dash, and inter-char timing from
them, updating as you go.

The good news is that the occasional substitution or missed element
isn't a huge problem. The end user can still read "SAPPY BIRHDAY" and
get the meaning.
(H > S by dropping a dot, and somehow we missed the - which is a T)

Also, hams tend to send morse in rather abbreviated text like this:

GD EVN OM HNDL HR IS DAVE LOC IS MUNCIE IN USA
WTHR HR IS BAD ICE N SNO

There are also "prosigns" to consider, where two chars are slid into
each other, like AR: *-*-* and they have special meanings.

If you're going to go to all that trouble, you might as well get your
ham licence. By the time you get this working, you'll be able to receive
5wpm and qualify for the tech plus licence.

1998\11\20@075825 by Peter L. Peres

picon face
On Thu, 5 Nov 1998, Gavin Jackson wrote:

> The first thing that comes to mind is to decode the
> dot dash dash dot into 0110 with a '1' representing
> dash and a '0' representing the dot. Then store a
> table in the PIC and do a simple compare through
> the table until a match is found. The only problem
> I see with this method is trying to tell the difference
> between a J ( . - - - ) and a 2 ( . . - - - ) which would be
> 0111 and 00111 respectively.

The usual way to encode decoded morse for id purposes is a 4-way code,
with 2 bits per symbol. That's like:

00 - dot
01 - dash
10 - long space
11 - error (neither of above) or end symbol.

Then you can pack these 4 per byte and life becomes easier. The end symbol
is used in the table and in the receiver buffer, in the latter it having
the meaning of 'error'. There are other schemes too. Note that you can
encode strings like this in tables. This is used for beacons, ids etc.

Of course you can compress the symbol recognition table by dropping the
MSB in each symbol using the code outlined above.

hope this helps,

Peter

1998\11\20@081653 by Harrison Cooper

flavicon
face
you need to be able to adjust for the WPM and CPM.  I have a morse
machine that this can be adjusted on.  A long time ago, say, some 20
years ago, one of the mags had a project to do this, but used all
discrets.  I had copied it, but it is long gone now.

{Quote hidden}

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...