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!!!!
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
|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.
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.
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
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.
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.)
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
>
> 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
--
---- ~~~~~~ -------- Nuno Filipe Freitas Pedrosa
-- ~~~~ ~~ ----- SIEMENS S.A. Portugal TEL: +351 1 4242454
- ~~~~ ~~ ---- EraseMENuno.Pedrosaspam_OUTTakeThisOuToen.siemens.de
- ~~~~ ~~ ---- "Smile, and tomorrow will be a better day!"
=======================================================================
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.
> ----------
> From: Nuno Pedrosa[SMTP:Nuno.Pedrosaspam_OUTOEN.SIEMENS.DE]
> Sent: Thursday, November 05, 1998 6:05 AM
> To: @spam@PICLISTKILLspamMITVMA.MIT.EDU
> Subject: Re: Morse Decoder
>
> 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:
> >
> > 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
>
> --
> ---- ~~~~~~ -------- Nuno Filipe Freitas Pedrosa
> -- ~~~~ ~~ ----- SIEMENS S.A. Portugal TEL: +351 1
> 4242454
> - ~~~~ ~~ ---- KILLspamNuno.PedrosaKILLspamoen.siemens.de
> - ~~~~ ~~ ---- "Smile, and tomorrow will be a better day!"
> ======================================================================
> =
>
> 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.
> > 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.
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...
>
> 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:
> >
> > 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
>
> --
> ---- ~~~~~~ -------- Nuno Filipe Freitas Pedrosa
> -- ~~~~ ~~ ----- SIEMENS S.A. Portugal TEL: +351 1 4242454
> - ~~~~ ~~ ---- RemoveMENuno.PedrosaTakeThisOuToen.siemens.de
> - ~~~~ ~~ ---- "Smile, and tomorrow will be a better day!"
> =======================================================================
--
---- ~~~~~~ -------- Nuno Filipe Freitas Pedrosa
-- ~~~~ ~~ ----- SIEMENS S.A. Portugal TEL: +351 1 4242454
- ~~~~ ~~ ---- spamBeGoneNuno.PedrosaspamBeGoneoen.siemens.de
- ~~~~ ~~ ---- "Smile, and tomorrow will be a better day!"
=======================================================================
> 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.
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.
___________________________________________________________________
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]
On Thu, 5 Nov 1998 18:03:57 +0000 "Peter L. Peres" <RemoveMEplpTakeThisOuTACTCOM.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...
___________________________________________________________________
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]
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
|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)
> |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)
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...
On Thu, 5 Nov 1998 13:05:53 +0000 Nuno Pedrosa
<EraseMENuno.PedrosaOEN.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]
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...).
>
> On Thu, 5 Nov 1998 13:05:53 +0000 Nuno Pedrosa
> <RemoveMENuno.PedrosaEraseMEEraseMEOEN.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]
--
---- ~~~~~~~ ------- Nuno Filipe Freitas Pedrosa
-- ~~~~ ~~ ----- SIEMENS S.A. Portugal TEL: +351 1 4242454
- ~~~~ ~~ ---- RemoveMENuno.Pedrosaspam_OUTKILLspamoen.siemens.de
- ~~~~ ~~ ---- "If it doesn't fit the hole, whack harder!"
=======================================================================
On Thu, 5 Nov 1998 18:03:57 +0000 "Peter L. Peres" <RemoveMEplpTakeThisOuTspamACTCOM.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...
___________________________________________________________________
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]
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.
___________________________________________________________________
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]
> 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.
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...
>
> 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:
> >
> > 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
>
> --
> ---- ~~~~~~ -------- Nuno Filipe Freitas Pedrosa
> -- ~~~~ ~~ ----- SIEMENS S.A. Portugal TEL: +351 1 4242454
> - ~~~~ ~~ ---- Nuno.PedrosaSTOPspamspam_OUToen.siemens.de
> - ~~~~ ~~ ---- "Smile, and tomorrow will be a better day!"
> =======================================================================
--
---- ~~~~~~ -------- Nuno Filipe Freitas Pedrosa
-- ~~~~ ~~ ----- SIEMENS S.A. Portugal TEL: +351 1 4242454
- ~~~~ ~~ ---- spamBeGoneNuno.PedrosaSTOPspamEraseMEoen.siemens.de
- ~~~~ ~~ ---- "Smile, and tomorrow will be a better day!"
=======================================================================
> > 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.
> 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.
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.
> ----------
> From: Nuno Pedrosa[SMTP:KILLspamNuno.PedrosaspamBeGoneOEN.SIEMENS.DE]
> Sent: Thursday, November 05, 1998 6:05 AM
> To: EraseMEPICLISTEraseMEMITVMA.MIT.EDU
> Subject: Re: Morse Decoder
>
> 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:
> >
> > 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
>
> --
> ---- ~~~~~~ -------- Nuno Filipe Freitas Pedrosa
> -- ~~~~ ~~ ----- SIEMENS S.A. Portugal TEL: +351 1
> 4242454
> - ~~~~ ~~ ---- @spam@Nuno.Pedrosa@spam@spam_OUToen.siemens.de
> - ~~~~ ~~ ---- "Smile, and tomorrow will be a better day!"
> ======================================================================
> =
>
ihug.co.nz
