By popular demand, the source code for the closed caption decoder that
Rich Ottosen and I designed is now available on the web. As with my other
PIC projects, it is covered by the GNU General Public License, Version 2.
The URL is
A copy of the text of the web page is attached below for your convenience.
Cheers,
Eric http://www.telebit.com/~eric/pic/
-----------------------------------------------------------------------------
Closed-Caption Decoder
This is a closed-caption decoder with serial output, based on a PIC16C71, an
Elantec EL4581C sync separator, and an LM393 dual comparator (for data slicing
with automatic threshold).
This project was partially inspired by the article "Build the Text Grabber" by
Kelly McArthur in the November 1994 issue of Electronics Now, but where Kelly
used an 8031 based design requiring a total of 16 chips, we found it possible
to implement essentially the same functionality with four by using a PIC.
The code for this project is available under the terms of the Free Software
Foundation's General Public License, Version 2. If you agree to the terms of
the license, you may obtain a copy via FTP.
The code won't do you much good if you don't have the schematic. I don't yet
have it available in electronic form, but if you want it send me email and
I'll arrange to get it to you.
Sync Separation
We originally used a common National Semiconductor LM1881 sync separator (as
did Kelly), but it seemed fairly unreliable so we switched to the Elantec
EL4581C, which is a pin-compatible improved performance part. It works much
better.
Because the field output of the LM1881 was particularly unreliable, we ended
up using only the composite sync output of the sync separator, and deriving
the horizontal sync, vertical sync and the field in software. The Elantec
part probably generates perfectly good sync and field outputs, but it would
be more trouble than it is worth to switch back.
Using other PICs
Rich has recently converted the code to run on a PIC16C56. The only advantage
of the '56 is that Rich had a Parallax downloader for the '5x family, and that
the '56 is cheaper than the '71. Microchip now offers a '61 (which is a '71
without the A/D converter), which probably has comparable price to the '56.
Rich points out that the '56 version of the code isn't very maintainable and
the RAM is completely full.
Microchip's recently announced PIC16C62X series parts may be an even better
fit for this application, since they have two built-in comparators which might
replace the separate LM393.
Other Articles
Another good article regarding capturing digital data from video signals is
"Exploring the Vertical Blanking Interval" by Mark Barnes, published in the
April 1994 issue of Circuit Cellar Ink. Mark's design is also 8031 based and
requires 24 chips, but in addition to closed captioning it also decodes
network time stamps, World System Teletext (WST), and North American Basic
Teletext Specification (NABTS).
Circuit Cellar also published in their May 1993 issue an article on the
Motorola MC68HC05CC1 chip, which is a single chip microcomputer specifically
designed for closed-caption decoding.
Standards
"Recommended Practice for Line 21 Data Service", ANSI/EIA-608-94, Sept. 1994
Electronic Industries Accociation
2500 Wilson Boulevard
Arlington VA 22201
American National Standards Institute
11 West 42nd Street
New York, NY 10036
"Television Captioning for the Deaf: Signal and Display Specifications"
Engineering Report No. E-7709-C
Public Broadcasting Service, May 1980
Public Broadcasting Service
1320 Braddock Place
Alexandria, VA 22314
"Telecaption II Decoder Module Performance Specification"
National Captioning Institute, May 1985
National Captioning Institute, Inc.
5203 Leesburg Pike
Falls Church, VA 22041
The schematics (in HPGL) and a theory of operation document for my PIC-based
closed caption decoder are now available in addition to the source code.
They may be downloaded from my PIC page. The URL is now: http://www.spies.com/~eric/pic/
>The schematics (in HPGL) and a theory of operation document for my PIC-based
>closed caption decoder are now available in addition to the source code.
>They may be downloaded from my PIC page. The URL is now:
> http://www.spies.com/~eric/pic/
>
>Cheers,
>Eric
>
>
I would like to build this unit Eric, could you tell me if there is a DOS
program to uncompress the GZ format. I have tried a program called STEALTH
without any success. Thanks for making your PIC expertise available to
those of us just starting to use these parts.
This is addressed to all PIC gurus on the list. The application is, you
guessed it, a DCC decoder which fits inside a tiny train. I am looking
for suggestions/ideas/advice.
What's DCC
----------
It is a packet based digital standard to drive toy trains. The signal swings
between +/- 12V(or so). The signal is connected to the rails and also provides
the power. The decoder reads the signal, decodes it and changes speed,
direction, lights, etc. accordingly. Each decoder has its own address allowing
each locomotive to be individually controlled by a single signal. Assorted
accessories like turnouts, signals, etc. may be driven off the same signal.
Neat, huh?
Which CPU?
----------
The PIC 16C84 is probably the only candidate in the PIC family or probably
any other family(?) for the following reasons.
1. Size. You can't use a DIP and an 18 pin SOIC is as small as you can get.
It is hard to squeeze in one or more support chips.
2. Data EEPROM. Settings need to be stored on power down. There isn't enough
space for a cell. This probably eliminates every other PIC.
3. ISP. A home-built might just be a little dearer than an off-the-shelf.
Besides the fun of developing something yourself, the other factor is that
you can 'upgrade' the software if necessary. This eliminates all EPROM/OTP
varieties as the OTP is unsuitable and the EPROM versions come only in DIP
or PLCC(?) and are too big.
DCC specs
---------
A 1 is a high followed by a low between 52 and 64 us. A 0 is a high followed
by a low between 90 and 10000 us. As the polarity is not fixed, the high and
low may be reversed. i.e. a 1 may be a low followed by a high between 52 and
64us.
All commands are sent as packets. A packet consists of atleast 10 1 bits, a
0 start bit, an 8 bit address, a 0 data start bit, one or more 8 bit data bytes
separated by 0 bits, a XOR 8 bit for error correction and a 1 packet end bit.
The idle condition is all 0s(?).
If the packet address matches the decoder address, the decoder acts on it. The
speed/direction packet is the most basic. More complex packets exist for other
functions like controlling lights, sound, accelaration/deaccelaration or even
reprogramming the decoder address. Packets are periodically retransmitted.
Decoder requirements
--------------------
The main packet is for control of motor speed and direction. The motor has
14 speeds. This is done by PWM. Other packets may be progressively implemented.
How?
----
Wish I knew. Can it be done at all? My usual ploy for reading bitstreams is to
have a periodic interrupt to sample the input. I do RS 232 using this method
with an interrupt rate of 104 us for 1200 baud input. To sample a 52us signal,
say 2 times, would give about 25 steps @ 4MHz or 60 steps @ 10MHz. The first is
just too difficult for me and the second is daunting. A counter/capture would
have been great but 16C84 cousins have already been ruled out. A Port B
interrupt may be a problem due to noise(?). One way around this could be a
40 us interrupt that enables the Port B interrupt. The Port B interrupt
disables itself and sets
off the time again. This will give the main loop quiet periods to get on
with life in general. There remains the option of a loop timed just
right which also does PWM. How difficult would this be? Are there any other
options I haven't considered? Don't tell me a device to run toy trains is too
much for a PIC or any general purpose micro to handle :-)
Misc
----
The damn things are cheap(AU$50?) and getting cheaper :-) So why build it?
Because
it is there. Because you can change the software to keep it up to date with new
packets. Because you can implement special requirements. Because using PICs
is fun.
Decoders for driving accessories don't have size restrictions and may have more
options for implementation.
The other missing bit is the control station. This could be a PC driving a PIC.
This, again, is a lesser problem and is solvable. It is also the most expensive
part of a DCC setup and is more easily justified on economic grounds.
Regards
Prashant
P.S. Looks like Digikey sells single 10 MHz SMT PIC 16C84s. Anybody know of a
source in my neck o' the woods(Australia)? The supplier here wants a minimum
order of 126 pieces and this part is not popular enough for a bulk buy. Any
suggestions, Don?
+----------------+ -------------------------------------------------
| | Prashant Bhandary
| +---+ | Spatial Information Systems Section
| | | | Roads and Traffic Authority
| | | | Rosebery NSW 2018, AUSTRALIA
| | | | Tel: +61-2-662 5299
| | +----+ | Fax: +61-2-662 5348
| | | | Email: spam_OUTprashbTakeThisOuTrta.nsw.gov.au
| +--------+ |
| Still a newbie | "2b|!2b" - William Shakespeare
+----------------+ -------------------------------------------------
Based on my command station work with DCC and PICs, I think it can be done
quite simply. The timing is from the zero crossings. Use the DCC signal
and set up the PIC to interrupt on port B change. Use the timer to time the
time between interrupts. Check the time and see if it is a one or a zero.
The code to decode the packet is pretty straight forward. I wrote a tool in
C to test my command station implimentation. I uses times from the MPSIM
trace file and determines if the timing is correct for the DCC signal. It
is just a development tool but I am willing to send it to you "as is" to
show how I detected packets. There are probably some improvements needed
but it is basically a decoder (Note that the time limits used are for the
command station, not the decoder since it is testing the command station).
I think you could do this with a 4MHz 16C84.
>Wish I knew. Can it be done at all? My usual ploy for reading bitstreams is to
>have a periodic interrupt to sample the input. I do RS 232 using this method
>with an interrupt rate of 104 us for 1200 baud input. To sample a 52us signal,
>say 2 times, would give about 25 steps @ 4MHz or 60 steps @ 10MHz. The first is
>just too difficult for me and the second is daunting.
Agreed.
>A counter/capture would
>have been great but 16C84 cousins have already been ruled out.
Agreed!!!
>A Port B
>interrupt may be a problem due to noise(?). One way around this could be a
>40 us interrupt that enables the Port B interrupt. The Port B interrupt
>disables itself and sets
>off the time again. This will give the main loop quiet periods to get on
>with life in general.
I think this is the most likely solution. I am not sure that noise is a
problem. Some test would tell but this is the first approach I would take.
Another solution to the noise would be to "filter" the DCC signal with
software. i.e. ignore polarity shifts that are smaller than the DCC 1's
time. I still think with a +- 12VDC (or more I use +-18VDC) signal, that
noise on the zero crossing should be rare. The protocol recommends
repeating packets as frequently as possible so it may not be a problem at all.
>There remains the option of a loop timed just
>right which also does PWM. How difficult would this be? Are there any other
>options I haven't considered? Don't tell me a device to run toy trains is too
>much for a PIC or any general purpose micro to handle :-)
>
The complexity of the timed loop and syncing with the command station
(streached zeros, timing tolerances etc) could be hard.
>Misc
>----
>The damn things are cheap(AU$50?) and getting cheaper :-) So why build it?
>Because
>it is there. Because you can change the software to keep it up to date with new
>packets. Because you can implement special requirements. Because using PICs
>is fun.
All very good reasons.
>
>Decoders for driving accessories don't have size restrictions and may have more
>options for implementation.
This may be the first thing to build, then use what you learn to build the
loco decoder. BTW I bought a decoder for $29.95 (US) to test my command
station. It may be a little large to put into an N scale loco though.
>
>The other missing bit is the control station. This could be a PC driving a PIC.
>This, again, is a lesser problem and is solvable. It is also the most expensive
>part of a DCC setup and is more easily justified on economic grounds.
>
I am working this part of the problem and have a workable solution. (As I
described via direct e-mail to you).
> This is addressed to all PIC gurus on the list. The application is, you
> guessed it, a DCC decoder which fits inside a tiny train. I am looking
> for suggestions/ideas/advice.
> Regards
>
> Prashant
>lots of snips--------------------------
> P.S. Looks like Digikey sells single 10 MHz SMT PIC 16C84s. Anybody know of a
> source in my neck o' the woods(Australia)? The supplier here wants a minimum
> order of 126 pieces and this part is not popular enough for a bulk buy. Any
> suggestions, Don?
Bob Nicol of Microzed in Armidale has a bigger stock of PIC parts than I
do, although SMT may also be a problem for him. I have never stocked them
for similar reasons. If that other mob has a stock of 4Mhz versions or
you have some, you could try pushing the chip speed a little.
With DIP parts, I have the 84/04 running off an 8Mhz crystal. Take your
pick out of the box. Any piece will work. When I told Gary Barnes of
Perth WA about this he sent me a little prototype board he had made up.
It has one of those 4 pin canned oscillators (ttl characteristics) and
will run any 84/04/P at 12 Mhz!!!
If you sent a man to the moon with it, watch out for legal stuff because
of manufacturers specs., but for 'you and I' projects, who cares!, as
long as it works 100%.
As I am sure you will be up against no stock in Australia. Do what I do,
go through digikey if you really need small quantities in a hurry at a
reasonable price.
At 08:36 AM 1/05/96 -0500, you wrote:
>
>>A Port B
>>interrupt may be a problem due to noise(?). One way around this could be a
>>40 us interrupt that enables the Port B interrupt. The Port B interrupt
>>disables itself and sets
>>off the time again. This will give the main loop quiet periods to get on
>>with life in general.
>
>I think this is the most likely solution. I am not sure that noise is a
>problem. Some test would tell but this is the first approach I would take.
>Another solution to the noise would be to "filter" the DCC signal with
>software. i.e. ignore polarity shifts that are smaller than the DCC 1's
>time. I still think with a +- 12VDC (or more I use +-18VDC) signal, that
>noise on the zero crossing should be rare. The protocol recommends
>repeating packets as frequently as possible so it may not be a problem at all.
The noise causing packets to be lost is not the problem. It may cause the
interrupt to be called too frequently to allow the main loop to run at all.
Filtering it out will still deprive the main loop its chance to run. The
main worry is it may interfere with the PWM. Noise would be due to dirty
track resulting in the signal dropping back to 0 intermittently. Pure +ve
to -ve transitions are hard to differentiate from drop to 0 without some
external components. So, whenever the train hits a dirty patch on the track,
it will mess up the PWM and falter. Hence my suggestion to block out
transitions for 40 us after a valid state change.
One possible way of differentiating between + to - transition and drops to
zero would be to use two inputs and do differential sensing in software.
The right place to do the PWM is another problem. PWM in the ISR can make
the ISR too long(?). Doing it in the main loop using the timer as a running
counter is an option.
Regards
Prashant
+----------------+ -------------------------------------------------
| | Prashant Bhandary
| +---+ | Spatial Information Systems Section
| | | | Roads and Traffic Authority
| | | | Rosebery NSW 2018, AUSTRALIA
| | | | Tel: +61-2-662 5299
| | +----+ | Fax: +61-2-662 5348
| | | | Email: prashbKILLspamrta.nsw.gov.au
| +--------+ |
| Still a newbie | "2b|!2b" - William Shakespeare
+----------------+ -------------------------------------------------
>The
>main worry is it may interfere with the PWM. Noise would be due to dirty
>track resulting in the signal dropping back to 0 intermittently. Pure +ve
>to -ve transitions are hard to differentiate from drop to 0 without some
>external components. So, whenever the train hits a dirty patch on the track,
>it will mess up the PWM and falter. Hence my suggestion to block out
>transitions for 40 us after a valid state change.
>
Oops, haden't thought about the dirty track problem. I like the
differential sensing approach and a block out for 40 usec should provide
"main loop" processing time. At what rate do you want to do the PWM to the
motor? If it is low enough, this approach should work.
>One possible way of differentiating between + to - transition and drops to
>zero would be to use two inputs and do differential sensing in software.
>
>The right place to do the PWM is another problem. PWM in the ISR can make
>the ISR too long(?). Doing it in the main loop using the timer as a running
>counter is an option.
What I have done in the command station to get it to fit into the 16c84 is
add a second timer in software that counts in 58usec intervals. It's not
accuracte enough for PWM but works great for key debounce and autorepeate.
Depending on the PWM period, you may be able to just increment a counter
every time the timer isr happens. (Note 58usec is the 1's time) The command
station uses tmr0 to generate the DCC signal.
Another question to address is how to convert the PIC output level to a
voltage to run the motor in such a small space? This doesn't need to be
solved yet but any ideas from the group would be usefull for planning.
How small does the decoder have to be? The one I am using is about 1" x
3/4" and fits OK in an HO scale locomotive (HO SCALE is 87:1) but won't fit
in N scale (160:1).
> track resulting in the signal dropping back to 0 intermittently. Pure +ve
> to -ve transitions are hard to differentiate from drop to 0 without some
> external components. So, whenever the train hits a dirty patch on the track,
If you can spare RA4 and one other I/O pin I think you could do this with
nothing but a couple of resistors and diodes (at least some of which you
would need to get the +-V into the PIC anyway). RA4 because it has a
Schmitt trigger, and if the thresholds are stable enough and you fiddle
with the biasing that could possibly be enough all by itself. But for
the cost of one more pin and a resistor you can add some
software-controlled hysteresis to what RA4 already provides. This was my
first thought, since the input thresholds for the Schmitt input at RA4
are only rather loosely spec'd. Looking at it again (in the table in
11.3 of the spec sheet), it's not even clear which side of the curve
those numbers are supposed to represent.
At 08:05 AM 2/05/96 -0500, you wrote:
>Another question to address is how to convert the PIC output level to a
>voltage to run the motor in such a small space? This doesn't need to be
>solved yet but any ideas from the group would be usefull for planning.
>
That shouldn't be difficult. I have envisaged two approaches. Use an H bridge
chip. One candidate which is available locally in one-ofs is UDN2916EB. This is
a 24 pin gull wing SMT. It has a lot more than I want - it is a dual H bridge
and has some current PWM circuitry. I would like to find a smaller single H
bridge.
The other alternative is to use 4 PIC outputs to drive a bridge. This will need
4 transistors+4resistors+4 diodes/1 bridge rectifier. This may even be smaller
and definitely cheaper than the single chip solution. Ordinary SMT components
are available at surplus stores at throwaway prices.
What are you using in your command station?
>How small does the decoder have to be? The one I am using is about 1" x
>3/4" and fits OK in an HO scale locomotive (HO SCALE is 87:1) but won't fit
>in N scale (160:1).
>
I don't know the exact dimensions but I am looking at building it first in HO
and then move to N. Some commercial decoders for N are in two parts to make
installation easier. The N scale loco I have got seems to have enough space for
a decoder about 3/4" x 3/4" x 1/4".
Regards
Prashant
+----------------+ -------------------------------------------------
| | Prashant Bhandary
| +---+ | Spatial Information Systems Section
| | | | Roads and Traffic Authority
| | | | Rosebery NSW 2018, AUSTRALIA
| | | | Tel: +61-2-662 5299
| | +----+ | Fax: +61-2-662 5348
| | | | Email: .....prashbKILLspam.....rta.nsw.gov.au
| +--------+ |
| Still a newbie | "2b|!2b" - William Shakespeare
+----------------+ -------------------------------------------------
At 06:21 PM 5/6/96 +1000, you wrote:
>
>What are you using in your command station?
>
The command station is currently using a power op-amp made by SGS Thomson,
part L165. It is only rated at 3A. I will be switching to a full H bridge
using discreet n-chan mosfets and a fet-driver to get more current. The
power op-amp might be a good approach for the decoder. The disadvantage for
a command station is it needs a bipolar supply. The decoder inherently has
a bipolar supply from the rails. The only package information I have is a
TO-220 style case. There may be a surface mount power op-amp out there
somewhere. It's easy to get the op-amp to do bipolar but a little harder to
do PWM. I haven't thought about how to make it do PWM, but it shouldn't be
too hard.
At 08:24 AM 6/05/96 -0500, you wrote:
>The command station is currently using a power op-amp made by SGS Thomson,
>part L165. It is only rated at 3A. I will be switching to a full H bridge
>using discreet n-chan mosfets and a fet-driver to get more current. The
>power op-amp might be a good approach for the decoder. The disadvantage for
>a command station is it needs a bipolar supply. The decoder inherently has
>a bipolar supply from the rails. The only package information I have is a
>TO-220 style case. There may be a surface mount power op-amp out there
>somewhere. It's easy to get the op-amp to do bipolar but a little harder to
>do PWM. I haven't thought about how to make it do PWM, but it shouldn't be
>too hard.
As you mentioned, power op amps need a bipolar supply which is a pain. Besides,
you aren't using the linear part. Single chip H bridges are easily available
which
make using discrete solutions unecessary. I don't know about the cost factor
though.
For example, the SGS Thomson L298 should give you enough juice. I don't remember
the rating but should be around 4A. It costs about AU$25. I remember seeing it
being used in a DCC station circuit and can dig it out for you if you like. For
low power applications I use a L293 rated at 600ma/1A. You get two in a 16/20
pin
DIP. I've used it to drive a stepper off a PC parallel port.
Regards
Prashant
+----------------+ -------------------------------------------------
| | Prashant Bhandary
| +---+ | Spatial Information Systems Section
| | | | Roads and Traffic Authority
| | | | Rosebery NSW 2018, AUSTRALIA
| | | | Tel: +61-2-662 5299
| | +----+ | Fax: +61-2-662 5348
| | | | Email: EraseMEprashbspam_OUTTakeThisOuTrta.nsw.gov.au
| +--------+ |
| Still a newbie | "2b|!2b" - William Shakespeare
+----------------+ -------------------------------------------------
Marv Isaacman, who prefers silent lurking on this mailing list to
flaunting his genius in front of us all by posting publicly, has come
up with the following optimization of the Gray-Code decoder I threw
together yesterday:
COUNT EQU [any register]
GRAY EQU [any other register]
; ENTER WITH THE GRAY-CODED NUMBER IN "GRAY". EXITS WITH THE
; DECODED NUMBER IN "GRAY".
DECODE:
MOVLW 8 ;SETUP TO DECODE 8 BITS.
MOVWF COUNT ;
LOOP:
RLF GRAY,W ;ROTATE THE NEXT BIT FROM BIT-
RLF GRAY ;POSITION 7 TO BIT-POSITION 0,
;LEAVING A COPY OF IT IN THE
;CARRY.
MOVLW 10000000B ;PREPARE TO INVERT THE NEXT BIT,
;IF NECESSARY.
SKPNC ;IF THE BIT WE JUST READ WAS
;EITHER A NON-INVERTED "0" OR
;AN INVERTED "1", SKIP AHEAD.
XORWF GRAY ;OTHERWISE, INVERT THE NEXT BIT.
DECFSZ COUNT ;HAVE WE DONE ALL 8 BITS?
GOTO LOOP ;IF NOT, LOOP BACK.
There was an RDS decoder project in Circuit Cellar May 1995 written by
Chris Morris, it uses a 16C84 and either an SAA6579 or TDA7330, plus an
LCD display of course. Unlike the Elektor designs, the source code can be
downloaded from their web site (but I don't remember the URL off hand).
If you can't find it, I'll find the source code and E-Mail it you, it's
lurking on my drive somewhere :-).
At 06:32 AM 4/30/97 -0500, you wrote:
> It would be interesting to see the theory of operation for the
>decoder, also.
I missed the start of this thread, apparently.
What is an "RDS Decoder" in the first place?
Thanks.
Andy
======================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865 USA
Electronics for Industry & R/C Hobbyists
"Go fast, turn right, and keep the wet side down!"
======================================================================
>> article if you want.
>
>There was an RDS decoder project in Circuit Cellar May 1995 written by
>Chris Morris, it uses a 16C84 and either an SAA6579 or TDA7330, plus an
>LCD display of course. Unlike the Elektor designs, the source code can be
>downloaded from their web site (but I don't remember the URL off hand).
>
>If you can't find it, I'll find the source code and E-Mail it you, it's
>lurking on my drive somewhere :-).
>
>Nigel.
At 09:17 30/04/1997 -0400, you wrote:
>I missed the start of this thread, apparently.
>
>What is an "RDS Decoder" in the first place?
RDS: Radio Digital System
Digital data which are sent at the same time with audio
signal. It usually contains radio name and other usefull
information such the other frequency where you can find
the same station.
Andy Kunz writes:
>What is an "RDS Decoder" in the first place?
RDS stands for Radio Data Service and uses one of the SCA frequencies
to send a stream of digital data which do such things as send the station's
call letters and a description of format as well as other short messages
like advertising or song titles. The plans are also to send selective calling
codes so that commuters on the North side of town, for example, will only
hear traffic reports which deal with the North side, etc. It is supposed
to be possible for RDS-equipped radios to scan the dial in a strange town
and find a station with a particular kind of music that you like even though
you've never been in this town before.
I just thought it would be interesting to know the SCA frequency
used and the data format. The frequency is probably either 67 or 92 KHZ,
but the data could be anything as long as it didn't cause too many sidebands.
RDS is not a subscription service like most SCA operations so we
aren't doing anything a little shady, here.
For those not familiar with United States government speak,
SCA stands for Subsidiary Carrier Authorization.
I have used a serial-in parallel-out along with a latched buffer.
This lets you get as many outs as you want (keep cascading them) for only 3
pins. (This is assuming
that speed is not that important.)
PIN 1: Serial Data Out
PIN 2: Serial Data Clock
PIN 3: Latch Clock (so that you only have stable outputs.)
You can use the same trick parallel-in serial-out for input!
In message <RemoveME199710250157.VAA01634KILLspamvulcan.addy.com>, "Alan G. Smith"
<agsSTOPspamspam_OUTPOBOXES.COM> writes
> I have used a serial-in parallel-out along with a latched buffer.
>This lets you get as many outs as you want (keep cascading them) for only 3
> pins. (This is assuming
>that speed is not that important.)
>PIN 1: Serial Data Out
>PIN 2: Serial Data Clock
>PIN 3: Latch Clock (so that you only have stable outputs.)
>
>You can use the same trick parallel-in serial-out for input!
On Fri, 24 Oct 1997 21:56:37 -0400 "Alan G. Smith" <KILLspamagsspamBeGonePOBOXES.COM>
writes:
> I have used a serial-in parallel-out along with a latched buffer.
Depending on what you're trying to do, a shift register may not be the
best choice. If you want a 4-16 decoder, two 74HC138 chips can be used
together to give 16 active low outputs (selected output low, all the
others high). To cascade two chips like this, connect the MSB select
line to an active-low enable pin of one chip and the active-high enable
pin of the other. If the outputs must not glitch, use another PIC pin to
control the other active low enables of both chips so they are not
enabled until the address is stable. I'm sure there are 16-output chips
but they are likely not as available and would also need more board space
than two 8-output units.
Another interesting part is the 74HC259 addressable 8-bit latch. It
would work well when there are several outputs with disjoint functions
since it can quickly set one high or low without affecting the others.
It needs 5 pins to control, but 4 can be reused since they are don't care
when the latch enable is high. The other inputs can't be changed while
enable is low. This method was used all over the Apple II.
The '259 has a Clear pin which defeats the memory function. Using this
mode, two '259 chips can build a 4-16 decoder with active high outputs
(selected output high, rest low). Connect the Clear pins of both chips
low, the 3 address lines together to the 3 select inputs, and the fourth
select input to the /E pin of the low chip and the D pin of the high
chip. The low chip's D pin is tied high and the high chip's /E pin is
tied low. There isn't another enable function so this decoder would
likely glitch. There is likely a solution to this requiring an inverter
or two.
>What do people use with a PIC16C84? I've run out of pins.
>
Alot of people like to use shift registers, two maybe three pins and
alot of possibilities. I often use 4-16 decoders, serial display chips, and
other serial stuff, I2C is really great because every device on the bus uses
only tow of the PICs pins. TTYL
74HC154 is a 4 to 16 decoder. Is this what you are looking for?
You can also use two 74HC138s (3 to 8 decoder) by hooking up the three
A0-A2 lines in common between the two HC138s and a fourth (A4) line on the
chip selects. Hook up to an active low chip select on one HC138 and
hook up to an active high chip select on the other HC138.
Hope this helps....if not, then hit the delete mail button.
> Is the address below your full address? Is there supposed to be some
> numbers or
> stree address?
>
> >> PLEASE SEND ME INFORMATION PIC DTMF DECODER AND DTMF RECEIVER
> >>
> >>
> >> ATT...
> >> MOISES COLLAZO COLON
> >> CAROLINA, PUERTO RICO
> >> RemoveMEMOIMAR@spam@spamBeGonePRTC.NET
Well - Puerto Rico isn't all that big I suppose. One of those places
where everybody knows everybody, and the postman is best paid<G>
Eric van Es wrote:
> david schmidt wrote:
> > Is the address below your full address? Is there supposed to be
> some
> > numbers or
> > stree address?
> > >> PLEASE SEND ME INFORMATION PIC DTMF DECODER AND DTMF RECEIVER
> > >> ATT...
> > >> MOISES COLLAZO COLON
> > >> CAROLINA, PUERTO RICO
> > >> .....MOIMARRemoveMEPRTC.NET
> Well - Puerto Rico isn't all that big I suppose. One of those places
> where everybody knows everybody, and the postman is best paid<G>
> Eric van Es | Cape Town, South Africa
However Moises lives at Carolina USA, so that makes it a little harder.
I have programmed a PIC16C64 to act as a binary to one of 24
decoder.
The unit worked OK for a while, then started to output
erratically.
I programmed a new PIC, but it does the same.
It worked once upon a time...anyone see what I've done wrong?
bsf STATUS,5 ;go to bank 1
movlw 0xFF
movwf TRISA ;set port a as inputs
clrf TRISB ;set ports,b,c & d as outputs
clrf TRISC
clrf TRISD
bcf STATUS,5 ;back to bank 0
main movf PORTA,W ;read select address into w
movwf ADRESS ;store this in ADRESS
call tableb ;call lookup table for port B
movwf PORTB ;put result out to port B
movwf ADRESS ;restore data from ADRESS
call tablec ;call lookup table for port C
movwf PORTC ;put result out to port C
movwf ADRESS ;restore data from ADRESS
call tabled ;call lookup table for port D
movwf PORTD ;put result out to port D
goto main ;repeat
On Tue, 24 Feb 1998 16:08:56 -0800 Ken Parkyn <RemoveMEk.parkynEraseMEKILLspamSCT.GU.EDU.AU>
writes:
>Hello all;
>
>I have programmed a PIC16C64 to act as a binary to one of 24
>decoder.
>The unit worked OK for a while, then started to output
>erratically.
>I programmed a new PIC, but it does the same.
The program looks like it will work OK.
Be sure to program the PIC with WDT off, or put a CLRWDT instruction in
the loop.
Another thing it is counting on is that the high bits of PORTA will read
zero. I'm not sure this is always the case with a 64. Or maybe your
power supply or clock is flakey. I would change a few things about the
program to make it more reliable:
* Put the setting of TRIS registers inside the loop. Sometimes a glitch
will corrupt the settings in the TRIS registers.
* Be sure PCLATH is set properly (for a program of this size, zero)
before accessing the tables.
* Test to be sure the value in ADRES is less than 24 before calling the
tables. Otherwise the PIC will crash.
_____________________________________________________________________
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
Or call Juno at (800) 654-JUNO [654-5866]
> anyone see what I've done wrong?
> ....
>
> main movf PORTA,W ;read select address into w
> movwf ADRESS ;store this in ADRESS
> call tableb ;call lookup table for port B
> movwf PORTB ;put result out to port B
> movwf ADRESS ;restore data from ADRESS
> call tablec ;call lookup table for port C
> movwf PORTC ;put result out to port C
> movwf ADRESS ;restore data from ADRESS
> call tabled ;call lookup table for port D
> movwf PORTD ;put result out to port D
> goto main ;repeat
Ken:
The second and third "movwf ADRESS" lines should read "movf
ADRESS,W".
> At 12:25 1998-02-24 -0500, Mike Keitz wrote:
>
>>* Put the setting of TRIS registers inside the loop. Sometimes
>> a glitch will corrupt the settings in the TRIS registers.
>
> :-O
> ?? What ?? How ? Glitch where? When?
Morgan, consider the proverbial stray cosmic ray, some RF
noise coupling to MCLR, mains interference causing a tran-
sient dip on the power rails, back EMF from a relay being
switched...
There are many ways in which the operation of an embedded
microcontroller can be disrupted. When it happens, it is
often the I/O pin control registers that are effected.
For these reasons, it is standard practice with embedded
controllers to place as much of the initialization code as
possible in the program's outermost loop. Then, if someone
starts the arc-welder (or that kiln controller switches on
a 5kW heating coil ;) ) and a spike gets through to the pic
(just enough to glitch TRISA but not kill the micro) then
next time around the loop it should be put right.
On Tue, 24 Feb 1998 23:43:41 +0100 Morgan Olsson <EraseMEmrtRemoveMESTOPspamINAME.COM> writes:
>At 12:25 1998-02-24 -0500, Mike Keitz wrote:
>
>-snip-
>
>>* Put the setting of TRIS registers inside the loop. Sometimes a
>glitch
>>will corrupt the settings in the TRIS registers.
>
>:-O
>?? What ?? How ? Glitch where? When?
The same sort of glitch that will upset the data in RAM, i.e. a rather
major one such as from static discharges, nearby lightning, turning the
power off then immediately back on, etc. The TRIS registers are after
all just registers like SRAM. It's good to write programs so that an
unexpected change of the contents of a chip register or RAM will
eventually "heal" after a period of temporary malfunction, rather than
requiring a complete reset.
_____________________________________________________________________
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
Or call Juno at (800) 654-JUNO [654-5866]
At 12:01 1998-02-25 +0000, Bob wrote:
>Morgan Olsson wrote:
>
>> At 12:25 1998-02-24 -0500, Mike Keitz wrote:
>>
>>>* Put the setting of TRIS registers inside the loop. Sometimes
>>> a glitch will corrupt the settings in the TRIS registers.
>>
>> :-O
>> ?? What ?? How ? Glitch where? When?
>
> Morgan, consider the proverbial stray cosmic ray, some RF
> noise coupling to MCLR, mains interference causing a tran-
> sient dip on the power rails, back EMF from a relay being
> switched...
Yes, but TRIS register is not more sensitive than other SFR:s or even RAM
Right?
> There are many ways in which the operation of an embedded
> microcontroller can be disrupted. When it happens, it is
> often the I/O pin control registers that are effected.
The port registers, but hardly the TRIS as they only control enable signals
to the output drivers.
> For these reasons, it is standard practice with embedded
> controllers to place as much of the initialization code as
> possible in the program's outermost loop. Then, if someone
> starts the arc-welder (or that kiln controller switches on
> a 5kW heating coil ;) ) and a spike gets through to the pic
> (just enough to glitch TRISA but not kill the micro) then
> next time around the loop it should be put right.
Right.
As many registers as possibly, including RAM should be often rewritten to
help against EMI, ESD cosmic, bad chip, etc (or sometimes better if
possible monitored to warn when something is out of order) But if a
register is rewritten with value from RAM nothing is gained as RAM is as
sensitive as the (RAM mapped) registers.
BTW, anyone know a method for the PIC to check the validity of it«s own ROM?
Some way to activate the ISP programming functions for read, then read
all ROM and calculate checksum.
One way would be to use a 12C508 just for checking the main PIC by
exersising standard ISP methods, or in systems with more than one micro
they can check each other.
Expensive, but maybe only way to do this?
I believe the high end PIC:s can use the 16-bit table read, but want a
method for 14-bit PIC:s
>> Morgan, consider the proverbial stray cosmic ray, some RF
>> noise coupling to MCLR, mains interference causing a tran-
>> sient dip on the power rails, back EMF from a relay being
>> switched...
>
> Yes, but TRIS register is not more sensitive than other SFR's or
> even RAM. Right?
This depends upon the topology of the chip. In general I
would expect the TRIS registers to be noticeably more sensitive
to glitches than other SFR's and RAM.
The direction control latch would normally be part of the
I/O 'macrocell' of each pin. Note that there is no TRIS
_register_ as such; there are a collection of latches dis-
tributed around the perimeter of the chip which happen to
be collectively addressable.
These latches are adjacent to, and part of, the I/O pin
circuit. It is these circuits that carry the largest
current flows in most systems, and which are the first
port of call for any interference entering the chip.
>> There are many ways in which the operation of an embedded
>> microcontroller can be disrupted. When it happens, it is
>> often the I/O pin control registers that are effected.
>
> The port registers, but hardly the TRIS as they only control enable
> signals to the output drivers.
As above, I think this distinction between the port latch
and the direction control latch is misplaced. Both latches
are usually co-located on the chip and subject to very similar
operating conditions.
>
> Hello all;
>
> I have programmed a PIC16C64 to act as a binary to one of 24
> decoder.
> The unit worked OK for a while, then started to output
> erratically.
> I programmed a new PIC, but it does the same.
> It worked once upon a time...anyone see what I've done wrong?
>
> code:
>
> title "chair"
> p=16c64
>
> PCL equ 02
> STATUS equ 03
> FSR equ 04
> PORTA equ 05
> PORTB equ 06
> PORTC equ 07
> PORTD equ 08
> PCL equ 02
> PCLATH equ 0A
> INTCON equ 0B
> OPTIONREG equ 81
> TRISA equ 05
> TRISB equ 06
> TRISC equ 07
> TRISD equ 08
> ;**************************************
> w equ 00
> f equ 01
> ADRESS equ 20
>
> ;**************************************
>
> bsf STATUS,5 ;go to bank 1
> movlw 0xFF
> movwf TRISA ;set port a as inputs
> clrf TRISB ;set ports,b,c & d as outputs
> clrf TRISC
> clrf TRISD
> bcf STATUS,5 ;back to bank 0
>
> main movf PORTA,W ;read select address into w
> movwf ADRESS ;store this in ADRESS
> call tableb ;call lookup table for port B
> movwf PORTB ;put result out to port B
> movwf ADRESS ;restore data from ADRESS
> call tablec ;call lookup table for port C
> movwf PORTC ;put result out to port C
> movwf ADRESS ;restore data from ADRESS
> call tabled ;call lookup table for port D
> movwf PORTD ;put result out to port D
> goto main ;repeat
>
> tableb addwf PCL,f
> retlw 01
> retlw 02
> retlw 04
> retlw 08
> retlw 10
> retlw 20
> retlw 40
> retlw 80
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> tablec addwf PCL,f
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 01
> retlw 02
> retlw 04
> retlw 08
> retlw 10
> retlw 20
> retlw 40
> retlw 80
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> tabled addwf PCL,f
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 00
> retlw 01
> retlw 02
> retlw 04
> retlw 08
> retlw 10
> retlw 20
> retlw 40
> retlw 80
> end
>
> TIA.
>
> ________________________________________
> Ken Parkyn email: spamBeGoneK.Parkyn@spam@sct.gu.edu.au
> Office of Technical Services, Electronics Workshop
> GRIFFITH UNIVERSITY Nathan Qld.4111 Australia
> P.O.Box 185 Ph:(07)3875 7289 Fax:(07)38757151
> ________________________________________
The value stored in ADRESS at the beginning of the programm must be
restored in W with the mnemonic 'movf ADRESS,W' and you wrote 'movwf
adresse' wich make an overmemory branch when the result of the table is
80 for example .
Nice work
>To All,
>
> Can anyone suggest an IC that will decode a 5x5 keypad?
>
>Much appreciated,
>
>Aaron
If software doesn't bother you, any PIC with 10 (5 in, 5 out) dedicated pins
will work. Look at Microchip's AN529. I used same principle to decode 40
switches keypad. It's also cheaper than standard keyboard encoders like
National's 74C923 (which is 20-key only).
Best regards,
--------------------------------------------------------
Kelly Kohls
Amateur Radio Callsign : N5TLE
Home E-Mail Address: RemoveMEkkohlsKILLspam@spam@juno.com
--------------------------------------------------------
_____________________________________________________________________
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
Or call Juno at (800) 654-JUNO [654-5866]
Greetings all,
Just a note for anybody interested, I have posted a new version of my DMX
decoder source code. In the original post I failed to comment a section
of the code. This has now been corrected. Comments or suggestions
invited.
P.S. By the way, I noticed the INCLUDE statement in the source file is
missing it's filename. Since the filename is enclosed within < >
characters, my browser is trying to interpret this as an HTML tag. The
filename should be <P16C76.INC>, the standard include file from
Microchip.
_____________________________________________________________________
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
Or call Juno at (800) 654-JUNO [654-5866]
Hi everybody, i'm looking for a paire of decoder, encoder, that as 3^10
address code and 10 bit of data. What is really important for me is the
10 bits of DATA... Please Help ! I can't find a 10 bit Data decoder and
encoder pair.
Thanks,
Sylvain
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
Sorry i did not give enough info on the decader encoder that i wanted,
it's for remote control communication. I check with Holtek but they only
have, max 8 bit of data... I want 10 bits of Data. Please help!
Sylvain
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
> I check with Holtek but they only
> have, max 8 bit of data... I want 10 bits of Data. Please help!
>
>
> i don't know all the available products out there, so i could
> be wrong... but my guess is that there is no such device.
>
> can't you just cascade several devices to get what you need?
>
On Tue, 7 Jul 1998 06:36:13 PDT, Sylvain Bilanger wrote:
>Hi everybody, i'm looking for a paire of decoder, encoder, that as 3^10
>address code and 10 bit of data. What is really important for me is the
>10 bits of DATA... Please Help ! I can't find a 10 bit Data decoder and
>encoder pair.
>
>Thanks,
>Sylvain
>
>
>
>______________________________________________________
>Get Your Private, Free Email at http://www.hotmail.com
>
The Trinary Encoder/Decoder Pair SN77702/SN77701 from Texas Instruments
is maybe that what you are looking for.
I 'm pretty new to PIC programming and what to make a DUAL TONE
MULTI-FREQUENCY decoder. It should preferably be handheld and have a fair
memory. Can any body give me advice,pointers, or anything else for a
newbie?
_____________________________________________________________________
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
Or call Juno at (800) 654-JUNO [654-5866]
> I 'm pretty new to PIC programming and what to make a DUAL TONE
> MULTI-FREQUENCY decoder. It should preferably be handheld and have a fair
> memory. Can any body give me advice,pointers, or anything else for a
> newbie?
If you want a hardware solution (a dedicated chip) you might look at the Holtek
HT9170 part at: http://www.digikey.com/D.DKS$336411H73157
$2.63 in onesies.
Also, there used to be a DTMF FAQ at:
www.paranoia.com/~filipg/LINK/F_DTMF.html
but I have not visited it in a while.
Not exactly what you wanted but perhaps there is a start in there somewhere.
Good luck!
Michael
*************************************************************************
When the way of the Tao is forgotten, kindness and ethics must be taught.
Men must learn to pretend to be wise and good. -- Lao Tzu
*************************************************************************
try to use the dedicated MT8870 IC. It is a DTMF decoder, with a 4-bit
parallel output, and a strobe line. I use the strobe line to control the
PIC INTR0 line. The AC characteristic of that IC is great, about 100 mV or
so drives it already. It requires an 3.58 MHz XTAL and the oscillation can
be used also to drive a PIC.
> I 'm pretty new to PIC programming and what to make a DUAL TONE
> MULTI-FREQUENCY decoder. It should preferably be handheld and have a fair
> memory. Can any body give me advice,pointers, or anything else for a
> newbie?
>
> _____________________________________________________________________
> 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
> Or call Juno at (800) 654-JUNO [654-5866]
>
>
> ghfkj D hum wrote:
>
> > I 'm pretty new to PIC programming and what to make a DUAL TONE
> > MULTI-FREQUENCY decoder. It should preferably be handheld and have a fair
> > memory. Can any body give me advice,pointers, or anything else for a
> > newbie?
>
<snip>
> If a software solution is your quest, I am not aware of any software encoders,
Here's the theory for a software decoder algorithm.
Except for a few caveats which I can't disclose, this algorithm works.
Scott
> *************************************************************************
> When the way of the Tao is forgotten, kindness and ethics must be taught.
> Men must learn to pretend to be wise and good. -- Lao Tzu
> *************************************************************************
> try to use the dedicated MT8870 IC. It is a DTMF decoder, with a 4-bit
> parallel output, and a strobe line. I use the strobe line to control the
> PIC INTR0 line. The AC characteristic of that IC is great, about 100 mV or
> so drives it already. It requires an 3.58 MHz XTAL and the oscillation can
> be used also to drive a PIC.
>
> Imre
>
>
<excerpt>
Hi all I have built myself a home phone management system
based on a PIC16C56. I would like to add an answering machine to it. I
don't want to get involved with tape mechanisms and such and so I have
decided on a solid state solution. I wonder if anyone knows of a single
chip solid state answering machine. I imagine there must be some very
cheap ones out there as full digital answering machines with up to 15
minutes message time sell for as low as $AU70. I am looking for the
cheapest solution with the simplest interface for a PIC. Thanks in
advance.
</excerpt>
Unfortunately I'm not writing to provide an answer to your question, but
it reminded me of my wishlist for a technology I'm sure will be with us
within the next year or so, and I was wondering if there was someone on
the piclist who had some more info about this...
My wishlist is namely that we will sometime soon see a realtime MPEG3
(MP3) decoder/encoder chip. I have hundreds of redundant 1Mb Eproms
lying in my attic just waiting for the right project. And I believe
that when the first small MP3 decoder chips becomes available, we
piclisters will be able to make terrific CD quality speech boards
cheaply and that is my main reason for still keeping all those EPROMS.
:)
So does anybody know if there is alreay a single chip MP3 decoder
available on the market or if any such a device is on the design boards
somewhere and when it will be available? I just know its bound to
happen sooner or later... I just wish they would hurry up with the
technology! ;)
Rgds
Werner
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
> <excerpt>
> Hi all I have built myself a home phone management system
> based on a PIC16C56. I would like to add an answering machine to it. I
> don't want to get involved with tape mechanisms and such and so I have
> decided on a solid state solution. I wonder if anyone knows of a single
> chip solid state answering machine. I imagine there must be some very
> cheap ones out there as full digital answering machines with up to 15
> minutes message time sell for as low as $AU70. I am looking for the
> cheapest solution with the simplest interface for a PIC. Thanks in
> advance.
> </excerpt>
>
> Unfortunately I'm not writing to provide an answer to your question, but
> it reminded me of my wishlist for a technology I'm sure will be with us
> within the next year or so, and I was wondering if there was someone on
> the piclist who had some more info about this...
>
> My wishlist is namely that we will sometime soon see a realtime MPEG3
> (MP3) decoder/encoder chip. I have hundreds of redundant 1Mb Eproms
> lying in my attic just waiting for the right project. And I believe
> that when the first small MP3 decoder chips becomes available, we
> piclisters will be able to make terrific CD quality speech boards
> cheaply and that is my main reason for still keeping all those EPROMS.
> :)
>
> So does anybody know if there is alreay a single chip MP3 decoder
> available on the market or if any such a device is on the design boards
> somewhere and when it will be available? I just know its bound to
> happen sooner or later... I just wish they would hurry up with the
> technology! ;)
It is already available. A collegue of mine is playing with one.
> <excerpt>
> Hi all I have built myself a home phone management system
> based on a PIC16C56. I would like to add an answering machine to it. I
> don't want to get involved with tape mechanisms and such and so I have
> decided on a solid state solution. I wonder if anyone knows of a single
> chip solid state answering machine. I imagine there must be some very
> cheap ones out there as full digital answering machines with up to 15
> minutes message time sell for as low as $AU70. I am looking for the
> cheapest solution with the simplest interface for a PIC. Thanks in
> advance.
> </excerpt>
>
> Unfortunately I'm not writing to provide an answer to your question, but
> it reminded me of my wishlist for a technology I'm sure will be with us
> within the next year or so, and I was wondering if there was someone on
> the piclist who had some more info about this...
>
> My wishlist is namely that we will sometime soon see a realtime MPEG3
> (MP3) decoder/encoder chip. I have hundreds of redundant 1Mb Eproms
> lying in my attic just waiting for the right project. And I believe
> that when the first small MP3 decoder chips becomes available, we
> piclisters will be able to make terrific CD quality speech boards
> cheaply and that is my main reason for still keeping all those EPROMS.
> :)
>
> So does anybody know if there is alreay a single chip MP3 decoder
> available on the market or if any such a device is on the design boards
> somewhere and when it will be available? I just know its bound to
> happen sooner or later... I just wish they would hurry up with the
> technology! ;)
>
> Rgds
> Werner
>
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com
>My wishlist is namely that we will sometime soon see a realtime MPEG3
>(MP3) ...
Just FYI, the ".MP3" format is not MPEG3. It's actually MPEG1, Layer 3.
>So does anybody know if there is alreay a single chip MP3 decoder
>available on the market or if any such a device is on the design boards
Yeah, it's been around for quite a while! It's part number MAS3507D
from Intermetall/Micronas. Have a look at gussie.alaska.net/acplay
for a really cool project using it from someone I know over on the
Atmel list.
Hello piclist people
Does anyone have the code for a Morse
decoder. It doesn't have to be all singing and dancing just the basics. I
want to see how it is done, how does it determine what speed it is being
sent at etc.
I have been working on my own algorithim to do this for a while now, but
other obligations prevent me from putting in all the time on it that I want
to. But as soon as I get it together, I'll send you a copy.
> From: Les <KILLspamlesspamBeGoneTOP204.FREESERVE.CO.UK>
> To: @spam@PICLISTSTOPspam@spam@MITVMA.MIT.EDU
> Subject: Morse decoder required
> Date: Sunday, November 01, 1998 4:06 PM
>
> Hello piclist people
> Does anyone have the code for a Morse
> decoder. It doesn't have to be all singing and dancing just the basics. I
> want to see how it is done, how does it determine what speed it is being
> sent at etc.
>
>
> Regards
> Les
Les wrote:
> Does anyone have the code for a Morse decoder. I saw a Velleman kit in the Map
lin catalogue.
Overpriced pre-blown micro and an LCD display.
Given these are the most expensive bits, why not
just get a tone decoder (e.g. XR2206, or NE567)
and use your PC to watch the demodulated
signal and decode it? It is not a huge signalling rate,
so software decoding should not be a high-stress app.
On top of that you can record traffic to disk.
If you still want your PIC to do the decoding,
you could get it to transmit the ASCII to the PC.
There are some PD programs for transmitting
receiving morse. One takes keyboard chars and
bleeps on the speaker to transmit, and listens
to a bit on the serial port handshake line
to receive.
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!!!!
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
I'm about to buy a new emulator. I will choose between RICE17A from Advanced
Transdata and ClearView Mathias from Tech Tools.
What do you gurus use? It's better to wait for MPLAB-ICE Emulator? I heard
the model 1000 will not be released until mid 99. Is that true?
The model 2000 is to expensive.
Regards,
Octavio
P.S. I will be out until next Friday and wont be able to read my e-mails
until them.
==============================================
Octavio Nogueira - nogueiraspamBeGonespamBeGonepropic2.com ICQ# 19841898
From the creator of ProPic, ProPic 2 now much better
New ProPic 2 homepage: http://www.propic2.com
PIC Programmer for Windows with down to earth price
==============================================
Les wrote:
>
> Hello piclist people
> Does anyone have the code for a Morse
> decoder. It doesn't have to be all singing and dancing just the basics. I
> want to see how it is done, how does it determine what speed it is being
> sent at etc.
>
> Regards
> Les
>I'm about to buy a new emulator. I will choose between RICE17A from Advanced
>Transdata and ClearView Mathias from Tech Tools.
>What do you gurus use? It's better to wait for MPLAB-ICE Emulator? I heard
>the model 1000 will not be released until mid 99. Is that true?
>The model 2000 is to expensive.
Octavio,
I use the ClearView Mathias (CVM) for everything except 17C development. I
MUCH prefer the CVM because it supports 20+ MHz operation (limited only by
bondouts), you can select just about any operation frequency you want (RICE
is limited to a handful, upper bound at 16MHz), and the CVM software is
much nicer. The _only_ reason I bought the RICE was because Tech Tools
doesn't have a 17C emulator.
Andy
==================================================================
Andy Kunz - Statistical Research, Inc. - Westfield, New Jersey USA
==================================================================
They list a Morse decoder kit w/ 16X1 lcd display kit for $70 US.
P.72 catalog #973.
I wrote an ASCII to Morse convertor for an old 8-bit palmtop a
few years ago - For some reason did'nt occur to me to try it the
other way - Sounds a bit more challenging. Think I'll take a shot
at it.
Have'nt heard from Maplins yet - Suspect you buried them... :)
> >I'm about to buy a new emulator. I will choose between RICE17A from
> >Advanced Transdata and ClearView Mathias from Tech Tools.
> >What do you gurus use? It's better to wait for MPLAB-ICE Emulator? I
> >heard the model 1000 will not be released until mid 99. Is that true?
> >The model 2000 is to expensive.
>
> I use the ClearView Mathias (CVM) for everything except 17C development.
> I MUCH prefer the CVM because it supports 20+ MHz operation (limited only
> by bondouts), you can select just about any operation frequency you want
> (RICE is limited to a handful, upper bound at 16MHz), and the CVM
> software is much nicer. The _only_ reason I bought the RICE was because
> Tech Tools doesn't have a 17C emulator.
I have a RICE17a, a couple of PICMasters and an ICEPIC.
Some weeks ago I said "whenever I use the RICE I find in myself new
capacities for hate and anger" and my opinion hasn't changed. The
only reason I bought the RICE was so that I could emulate a 17c43
at 32MHz, something my PICMasters won't do. I can't wait to get my
hands on an MPLAB-ICE so I can take my RICE and jump on it.
I'm normally such a calm, relaxed, chillin' dude, too...
I've never used a Clearview emulator so I can't comment about them,
but I'd really hesitate to recommend a RICE.
- Andy.
PS - I'm probably being unfair to the RICE. Most of _my_ problems with it
are concerned with its PC software which is awful. Smart
Communications, (the people I bought my RICE from) have been nothing
other than courteous and generous with their time on the occassions
I've had to call them. I have also heard that Advanced Transdata are
very helpful.
----------------------------------------------------------
Andrew David, Software Manager, Ultronics Ltd, Cheltenham. spamBeGoneakdavidUltronics.co.ukhttp://www.ultronics.com/
----------------------------------------------------------
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
- ~~~~ ~~ ---- Nuno.PedrosaRemoveMEoen.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:EraseMENuno.PedrosaSTOPspamRemoveMEOEN.SIEMENS.DE]
> Sent: Thursday, November 05, 1998 6:05 AM
> To: spam_OUTPICLISTRemoveMEEraseMEMITVMA.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
> - ~~~~ ~~ ---- TakeThisOuTNuno.PedrosaRemoveME@spam@oen.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
> - ~~~~ ~~ ---- EraseMENuno.PedrosaRemoveMEoen.siemens.de
> - ~~~~ ~~ ---- "Smile, and tomorrow will be a better day!"
> =======================================================================
--
---- ~~~~~~ -------- Nuno Filipe Freitas Pedrosa
-- ~~~~ ~~ ----- SIEMENS S.A. Portugal TEL: +351 1 4242454
- ~~~~ ~~ ---- spamNuno.Pedrosa.....spamoen.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" <.....plpspam.....ACTCOM.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]
For anybody that is interested, I have posted the second page of my DMX
receiver schematic on my homepage. I hope to have the first page scanned
and posted by Friday (Nov. 6) afternoon. If there are any questions, let
me know. Also, all integrated circuits in the circuit should have 0.1 uF
bypass capacitors on the supply pins. I forgot to include these on the
schematic.
___________________________________________________________________
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
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
<spamBeGoneNuno.PedrosaRemoveMEEraseMEOEN.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.PedrosaKILLspamRemoveMEOEN.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
- ~~~~ ~~ ---- TakeThisOuTNuno.Pedrosaoen.siemens.de
- ~~~~ ~~ ---- "If it doesn't fit the hole, whack harder!"
=======================================================================
For anybody that is interested, I have posted the second page of my DMX
receiver schematic on my homepage. I hope to have the first page scanned
and posted by Friday (Nov. 6) afternoon. If there are any questions, let
me know. Also, all integrated circuits in the circuit should have 0.1 uF
bypass capacitors on the supply pins. I forgot to include these on the
schematic.
___________________________________________________________________
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
or call Juno at (800) 654-JUNO [654-5866]
On Thu, 5 Nov 1998 18:03:57 +0000 "Peter L. Peres" <spamplpACTCOM.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
> - ~~~~ ~~ ---- @spam@Nuno.Pedrosa.....spamoen.siemens.de
> - ~~~~ ~~ ---- "Smile, and tomorrow will be a better day!"
> =======================================================================
--
---- ~~~~~~ -------- Nuno Filipe Freitas Pedrosa
-- ~~~~ ~~ ----- SIEMENS S.A. Portugal TEL: +351 1 4242454
- ~~~~ ~~ ---- spamNuno.Pedrosa..........oen.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:Nuno.Pedrosa.....OEN.SIEMENS.DE]
> Sent: Thursday, November 05, 1998 6:05 AM
> To: KILLspamPICLISTspam_OUTMITVMA.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_OUTNuno.PedrosaTakeThisOuToen.siemens.de
> - ~~~~ ~~ ---- "Smile, and tomorrow will be a better day!"
> ======================================================================
> =
>
I am attempting to use Holtek's HT-12D/HT-12E encoder and decoder
pair for some basic RF transmission. I have the chips on a prototype
board and have gotten the encoder to transmit properly, but cannot get
the decoder to work properly. The strange thing is that when I feed the
output of the encoder directly into the input for the decoder, I do see a
high transition on the VT, valid transmission pin. However, I do not see
the any of the four data bits changing, regardless of their state. Any
clue or advice? I have tried to contact Holtek via email, but so far no
reply.
Just a few things to check quick,
Make sure the code pins are in the same state on both receiver and
transmitter.
Make sure to match the two clock frequencies,
The recommended is fosc(HT-12D) around 50* fosc(HT-12E)
Quick values from the book 1.1Mohm/3KHz/HT-12E and 62KOhm/150KHz/HT-12D
What kind of RF xmitter pair is involved ?
I am using a set of 303MHz RF's from DVP, Inc. Concerning the
Holtek encoder/decoder, I do have the correct resistors and address pins
set for both. I am stumped for sure! Thanks for the suggestions, thoguh!
I am PeterS from DVP, if You still got the problem let me know how can I
help You.
You can send me a private mail .....schupet.....RemoveMEdvp.com.
If You prefer call me at (818) 541-9029
What are the data pins being activated with? I once used diodes to isoat
e
buttons which also supply power. Problem with this is power supply was approx.
.7 volts less than the data pin. It cause the same problem you describe.
Sometimes it didn't work at all. Diodes must also be added going to the data
pins to drop the voltage equally. Hopefully this will help. Matt
>
> To all,
>
> I am attempting to use Holtek's HT-12D/HT-12E encoder and decoder
> pair for some basic RF transmission. I have the chips on a prototype
> board and have gotten the encoder to transmit properly, but cannot get
> the decoder to work properly. The strange thing is that when I feed the
> output of the encoder directly into the input for the decoder, I do see a
> high transition on the VT, valid transmission pin. However, I do not see
> the any of the four data bits changing, regardless of their state. Any
> clue or advice? I have tried to contact Holtek via email, but so far no
> reply.
>
> Thanks,
>
> Aaron Hickman
I don't have the data book handy, but I seem to recall that these chips used
different resistor values for the same clock frequency. Try double checking
the chart on the data sheet to make sure they are running at the same speed.
> To all,
>
> I am attempting to use Holtek's HT-12D/HT-12E encoder and decoder
> pair for some basic RF transmission. I have the chips on a prototype
> board and have gotten the encoder to transmit properly, but cannot get
> the decoder to work properly. The strange thing is that when I feed the
> output of the encoder directly into the input for the decoder, I do see a
> high transition on the VT, valid transmission pin. However, I do not see
> the any of the four data bits changing, regardless of their state. Any
> clue or advice? I have tried to contact Holtek via email, but so far no
> reply.
>
> Thanks,
>
> Aaron Hickman
OK, I admit I wasn't paying much attention to the thread when it was
going around. So, forgive me for asking, did anyone keep the final
outcome of this? What about STAMP II apps for this maybe?
I want to build a decoder for both DTMF and single tone frequencies,
so I can attach to my scanner or HT when the local ARES group sends
a call out...
Well, searching thru my saved mail, and URL's, I've found a couple of DTMF
generators using the PIC, but it seems most of the decoders are using
the M8870 DTMF decoders. But I am sure there was some discussion on using a
PIC directly for this. Maybe not. Since I want both DTMF and single tone,
maybe the best route is to have two circuits one for each.
Or, has anyone used a frequency to voltage converter and then read into a PIC
and used a LUT? I'm trying to get this to a single chip solution if I can.
> Well, searching thru my saved mail, and URL's, I've found a couple of DTMF
> generators using the PIC, but it seems most of the decoders are using
> the M8870 DTMF decoders. But I am sure there was some discussion on using a
> PIC directly for this. Maybe not. Since I want both DTMF and single tone,
> maybe the best route is to have two circuits one for each.
>
> Or, has anyone used a frequency to voltage converter and then read into a PIC
> and used a LUT? I'm trying to get this to a single chip solution if I can.
>
> comments?
John Payson, Mike Keitz, myself and perhaps others have attempted DTMF
decoding with a PIC. John and I are unable to give you any software (we
did not work together) because of the terms under which we developed our
software. However, you can get the gist of the theory from here:
It describes the technique I used. And if I recall correctly, it's the
technique Mike used too.
I don't know about Mike or John, but I found that a 'single-chip' solution
was not possible. In other words, I had to have a little analog signal
processing. However, for your application it sounds like (from an
earlier post) that you're willing to accept some errors. If so then the
'analog signal processing' could be just a simple high pass (passive)
filter.
>Or, has anyone used a frequency to voltage converter and then read into a PIC
>and used a LUT? I'm trying to get this to a single chip solution if I can.
I'm looking for a decent F-to-V circuit.
Anybody have one I can copy?
Andy
==================================================================
Andy Kunz - Statistical Research, Inc. - Westfield, New Jersey USA
==================================================================
Brurr-Brown makes a VFC32 chip which works excelently as either v-f or
f-v.
------------------------------------------------------------------------------
A member of the PI-100 Club:
3.1415926535897932384626433832795028841971693993751
058209749445923078164062862089986280348253421170679
> >Or, has anyone used a frequency to voltage converter and then read into a PIC
> >and used a LUT? I'm trying to get this to a single chip solution if I can.
>
> I'm looking for a decent F-to-V circuit.
>
> Anybody have one I can copy?
>
> Andy
>
> ==================================================================
> Andy Kunz - Statistical Research, Inc. - Westfield, New Jersey USA
> ==================================================================
>
Hi,
the ideal decoder device of DTMF is the MT8870. It is cheap, reliable,
etc. I use it with PIC. 4 data and 1 IT lines are sufficient if I
recall...
I hope this helps.
Imre
On Thu, 17 Dec 1998, Harrison Cooper wrote:
> OK, I admit I wasn't paying much attention to the thread when it was
> going around. So, forgive me for asking, did anyone keep the final
> outcome of this? What about STAMP II apps for this maybe?
>
> I want to build a decoder for both DTMF and single tone frequencies,
> so I can attach to my scanner or HT when the local ARES group sends
> a call out...
>
>
Hi,
theoretically, there is another interesting approach:
one can build a Fourier spectrum analyser and then evaluate the power
spectra. In the Embedded Controller Handbook (AN's) there is one example
for 17C42. Such way, both dual-tone and single-tone can be reliable
detected... I did not tried it but maybe I will do it in the future...
Imre
> Well, searching thru my saved mail, and URL's, I've found a couple of DTMF
> generators using the PIC, but it seems most of the decoders are using
> the M8870 DTMF decoders. But I am sure there was some discussion on using a
> PIC directly for this. Maybe not. Since I want both DTMF and single tone,
> maybe the best route is to have two circuits one for each.
>
> Or, has anyone used a frequency to voltage converter and then read into a PIC
> and used a LUT? I'm trying to get this to a single chip solution if I can.
>
> comments?
>
>
> Hi,
> theoretically, there is another interesting approach:
> one can build a Fourier spectrum analyser and then evaluate the power
> spectra. In the Embedded Controller Handbook (AN's) there is one example
> for 17C42. Such way, both dual-tone and single-tone can be reliable
> detected... I did not tried it but maybe I will do it in the future...
> Imre
In theory there's not much difference between theory and practice; in
practice though, there is... :)
I would recommend against this method for two reasons:
1) FFT computation in real time for a pic sampling signals at a rate up to
3 or 4kHz is (extremely) difficult. Perhaps the hardware multiplier on the
17C core speeds things up quite a bit. However, I'd be really surprised if
it was done (or doable).
2) One of the 'problems' with FFT's is that the frequency bins are evenly
spaced. However, for DTMF signals they're logarithmically spaced. Ideally,
you'd like the FFT bins to lie directly on top of the DTMF frequencies. At
reasonable sample rates it's impossible to achieve this. Additionally, the
FFT produces much more information than you need. You're really just
interested in the magnitude of the DTMF tones and the total energy in the
signal. The FFT decomposes the signal into many, many frequency bins.
You may wish to look at Analog Devices' DSP apnotes. They discuss this
more thoroughly. Their solution is to compute 16 DFT's: 8 at the DTMF
tones and 8 at the 2nd harmonic of DTMF tones. The second set presumably
allows one to ascertain whether a 'pure' DTMF tone was present or whether
the DTMF energy is a harmonic of some lower frequency present signal. On
comp.dsp I have read that people have found this technique to be flawed.
But I haven't tried it my self (at least not as described here).
At 09:12 12/19/98 -0800, Scott Dattalo wrote:
>You may wish to look at Analog Devices' DSP apnotes. They discuss this
>more thoroughly. Their solution is to compute 16 DFT's: 8 at the DTMF
>tones and 8 at the 2nd harmonic of DTMF tones. The second set presumably
>allows one to ascertain whether a 'pure' DTMF tone was present or whether
>the DTMF energy is a harmonic of some lower frequency present signal. On
>comp.dsp I have read that people have found this technique to be flawed.
>But I haven't tried it my self (at least not as described here).
if the goal is to find out whether a certain filtered band is a base
frequency of a tone or a harmonic of some other, the second harmonic is not
very suitable, because it would be part of both, whether the filtered
frequency is a base frequency or a power of two harmonic of some other
frequency -- unless you can make sure the DTMF tones are pure sine. i'd
guess that is rarely the case.
> Hi,
> theoretically, there is another interesting approach:
> one can build a Fourier spectrum analyser and then evaluate the power
> spectra. In the Embedded Controller Handbook (AN's) there is one example
> for 17C42. Such way, both dual-tone and single-tone can be reliable
> detected... I did not tried it but maybe I will do it in the future...
> Imre
|I would recommend against this method for two reasons:
|1) FFT computation in real time for a pic sampling signals at a rate up to
|3 or 4kHz is (extremely) difficult.
|2) One of the 'problems' with FFT's is that the frequency bins are evenly
|spaced. However, for DTMF signals they're logarithmically spaced. Ideally,
|you'd like the FFT bins to lie directly on top of the DTMF frequencies.
Using a pair of DFT's (discrete Fourier transform) it is possible
to look for a the existence of any single frequency in a signal
which may also contain other stuff. Performing /N/ DFT's will
take /N/ times as long as performing one, but if you only need a
few, that's not a problem.
An FFT is primarily useful in cases where you want to decompose
a "sample" [e.g. 256 A/D readings taken at an 8192Hz rate] of a
signal into "all" its constituent frequencies; the result of the
FFT will be equivalent to the result of running a pair of DFT's
on every frequency which divides into the sample length. The FFT
will be much faster than running all the DFT's individually, but
will take much longer than running a small handful of DFT's.
Note that when running DFT computations, you may (and almost
certainly should) perform the multiply-accumulate-sum operations
on the fly. Beyond that, there are some gotchas to be aware of:
[1] Multiplies on anything short of a 17Cxx part are going to be
expensive. Rather than using a sinewave as the integrating
waveform, you may use a simpler step wave. My favorite wave-
form for this purpose is 1/3 period at +1, 1/6 at zero, 1/3
at -1, and 1/6 at zero. This waveform has no harmonic content
at multiples of 2 or 3, and its harmonic content drops prop-
ortional to frequency (the first non-zero harmonic is the fifth
harmonic at 1/5 strength).
[2] Another way to simplify your life is to use a zero-crossing
detector rather than an A/D. I've done a DTMF defector using
just the 16C622's comparator and it worked decently. Using an
ADC input is better, but it's more expensive and requires more
math.
[3] Rather than running DFT's on chunks of, e.g. 1/32 of a second
and having them independent, it's better to use sliding-window
filtering and averaging techniques to combine them. This is
especially important if the frequency is not a multiple of the
sample-group length.
|You may wish to look at Analog Devices' DSP apnotes. They discuss this
|more thoroughly. Their solution is to compute 16 DFT's: 8 at the DTMF
|tones and 8 at the 2nd harmonic of DTMF tones. The second set presumably
|allows one to ascertain whether a 'pure' DTMF tone was present or whether
|the DTMF energy is a harmonic of some lower frequency present signal. On
|comp.dsp I have read that people have found this technique to be flawed.
|But I haven't tried it my self (at least not as described here).
A better approach (which I've done on a DSP--it'd be beyond the
abilities of a PIC) is to have two detectors at each frequency,
one of which is more discriminating than the other. Then require
that the more discriminating detector pickup be at least a certain
fraction of the less detecting one. This results in negative sen-
sitivity near the frequency of interest, but a very narrow spike in
sensitivity at the desired frequency. Since more discriminating
filters have slower response times, it's necessary to slow down
the response of the less discriminating filter to match. Using
these techniques, though, can produce outstanding DTMF detection
and false-tone rejection.
Steve Tomes wrote:
>
> Hi all,
>
> Can anyone sudjest a chip for Manchester encoder/decoder ...for dara
> rates <115K baud. I wish to use with RFM TR1000 trancievers.
A Scenix SX. I am also playing with some RF stuff on the
Scenix. You get much more room to work with. You might be
able to do the encoding/decoding in a PIC, but it will be
nasty if you also want to do other stuff.
On Thu, 31 Dec 1998 07:47:54 +0200 Tjaart van der Walt
<TakeThisOuTtjaartKILLspam@spam@WASP.CO.ZA> writes:
>Steve Tomes wrote:
>>=20
>> Hi all,
>>=20
>> Can anyone sudjest a chip for Manchester encoder/decoder ...for dara
>> rates <115K baud. I wish to use with RFM TR1000 trancievers.
>A Scenix SX.
No need to automatically reach for SX chips ro PLDs, I've found a PIC
quite capable at least up to 10 or 20 Kbps. Manchester is easy to encode
and decode. PICs or other chips with hardware SPI ports could probably
use those ports to send and receive Manchester at hundreds of Kbps with a
few external gates.
At the decoder, a "one-shot" type of decoder will work fine for testing
or for data being sent over wires. When data is sent by radio it tends
to get distorted and noisy, so a more robust decoder including some sort
of PLL would probably work better to maximize the useable transmission
range.
___________________________________________________________________
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 usually use a '138 and a '151 (3-8 decoder, 8-3 mux) to scan up to a 64 key
keyboard. Use the output of the mux as an input to see if a key is pressed.
Operation is simple:
for i=0 to 63
port =i
if input low then
//key has been pressed, do something
endif
next i
Uses 7 pins, but the 'ls (or hc or whatever) chips are cheap and multiple
sourced. Can also prefix the address pins with a 6 bit counter, then you can
use 3 wires. Clear counter, clock counter, check input.
Philosophic note:
There is no "best" keyboard encoder -- or usually, anything other function.
The above is a low cost hardware solution, rapid machine execution, and
trivial programming. Shift registers save pins, but require more programming
and longer execution times. Also harder for a newbie to debug. I am building
things in 100 quantities, and adding a $.05 part to save an hour of
programming or design time is about a wash. If you're doing this for fun,
designing stuff for 100k/year production rates, or building life-support
equipment, you get different answers. I have designed stuff for
geosynchronous weather satellites (production rates 1/year) and video games (1
million/year), and believe me, you get different answers for the same problem.
Hi everybody can anyone help me in my project? I want to use a pic to
log dialed numbers of all calls on my telephone line so if you have any
application note I appreciate also if you know about a chip can decode
DTMF. thanks in advance
A DTMF decoder chip I have had succes with is the CM8870C from Mitel. It is
only about $A2.00. It runs off a colour burst crystal which is also cheap
and can be used to run your pic as well.
I'm sorry if this is considered off-topic.
I was just sitting here wondering if it would be hard to write PIC
software to decode MP3 songs. can the pic run fast enough to get the
data from where ever it's stored (a whole separate issue), decompress
the data, and then convert it to an analog signal(PWM?)? seems like it
might, but i am relatively new to all this.
maybe you could use a portable CD player to be the storage medium, or
a general chassis for portable MP3 player (i know that these already
exist, just my engineering mind running free here)just a little
modification there <G>...
anyways, just curious
At 06:17 PM 1/26/99 PST, you wrote:
>I'm sorry if this is considered off-topic.
> I was just sitting here wondering if it would be hard to write PIC
>software to decode MP3 songs. can the pic run fast enough to get the
>data from where ever it's stored (a whole separate issue), decompress
>the data, and then convert it to an analog signal(PWM?)? seems like it
>might, but i am relatively new to all this.
> maybe you could use a portable CD player to be the storage medium, or
>a general chassis for portable MP3 player (i know that these already
>exist, just my engineering mind running free here)just a little
>modification there <G>...
>anyways, just curious
>
>thanks,
>Steve K.
>
>P.S. please cc: responses to TakeThisOuTsk123spam_OUTaol.com
>
>______________________________________________________
>Get Your Private, Free Email at http://www.hotmail.com
Sorry, but decoding MP3 requires one heck of a CPU. It pushes a 486dx/4
100 mhz to its upper limits. You might be able to use the PIC to control
some sort of specialized decoder, but a PIC just doesn't have the power to
decode a MP3 by itself. That's MP3 handhelds like the RIO (by Diamond I
think) cost so much... they have a pretty powerful CPU or DSP built in.
Hope I helped. I've been lurking on this list for a while, but have not
said much!
>At 06:17 PM 1/26/99 PST, you wrote:
>>I'm sorry if this is considered off-topic.
>> I was just sitting here wondering if it would be hard to write PIC
>>software to decode MP3 songs. can the pic run fast enough to get the
>>data from where ever it's stored (a whole separate issue), decompress
>>the data, and then convert it to an analog signal(PWM?)? seems like it
>>might, but i am relatively new to all this.
>> maybe you could use a portable CD player to be the storage medium, or
>>a general chassis for portable MP3 player (i know that these already
>>exist, just my engineering mind running free here)just a little
>>modification there <G>...
>>anyways, just curious
>>
>>thanks,
>>Steve K.
>>
>>P.S. please cc: responses to .....sk123EraseMEaol.com
>>
>>______________________________________________________
>>Get Your Private, Free Email at http://www.hotmail.com
>
>Sorry, but decoding MP3 requires one heck of a CPU. It pushes a 486dx/4
>100 mhz to its upper limits. You might be able to use the PIC to control
>some sort of specialized decoder, but a PIC just doesn't have the power to
>decode a MP3 by itself. That's MP3 handhelds like the RIO (by Diamond I
>think) cost so much... they have a pretty powerful CPU or DSP built in.
>Hope I helped. I've been lurking on this list for a while, but have not
>said much!
>
>
>-- Dennie Lee --
>spamBeGonedwlee1RemoveMEbbtel.com ICQ: 19351768
>http://www.uofl.edu/~dwlee001 <- Being Rebuilt, painfully slowly!
not even close
you need a MUCH more powerfull proccesor
>I'm sorry if this is considered off-topic.
> I was just sitting here wondering if it would be hard to write PIC
>software to decode MP3 songs. can the pic run fast enough to get the
>data from where ever it's stored (a whole separate issue), decompress
>the data, and then convert it to an analog signal(PWM?)? seems like it
>might, but i am relatively new to all this.
> maybe you could use a portable CD player to be the storage medium, or
>a general chassis for portable MP3 player (i know that these already
>exist, just my engineering mind running free here)just a little
>modification there <G>...
>anyways, just curious
>
>thanks,
>Steve K.
>
>P.S. please cc: responses to .....sk123EraseMEaol.com
>
>______________________________________________________
>Get Your Private, Free Email at http://www.hotmail.com
Since I know almost nothing about the MP3 standard, I am getting in way
over my head, but I don't see why it wouldn't be possible for a PIC to
perform almost ANY decoding. It is just an issue of how long it takes to do
it, and how much storage space it needs to store the results.
If one were willing to interface an IDE hard drive (or LOTS of SRAM or
DRAM) to one of the higher-end PICs, have it spend a few minutes decoding
an MP3 selection into raw wave data, and then just feed the bytes to a DAC,
I don't see why it COULDN'T be done, although, since it might take several
minutes to perform the operation and require quite a bit of storage space,
it might defeat the purpose of using the MP3 format.
Another option might be trying one of the SCENIX chips (50MIPS or
apparently soon to be at 100MIPS). I don't know if they are powerful
enough, but there are also relatively simple embedded versions of the MC68K
processor.
>not even close
>you need a MUCH more powerfull proccesor
>
>>I'm sorry if this is considered off-topic.
>> I was just sitting here wondering if it would be hard to write PIC
>>software to decode MP3 songs. can the pic run fast enough to get the
>>data from where ever it's stored (a whole separate issue), decompress
>>the data, and then convert it to an analog signal(PWM?)? seems like it
>>might, but i am relatively new to all this.
>> maybe you could use a portable CD player to be the storage medium, or
>>a general chassis for portable MP3 player (i know that these already
>>exist, just my engineering mind running free here)just a little
>>modification there <G>...
>>anyways, just curious
>>
>>thanks,
>>Steve K.
>>
>>P.S. please cc: responses to spamsk123spam_OUT@spam@aol.com
>>
>>______________________________________________________
>>Get Your Private, Free Email at http://www.hotmail.com
>
Hi Sean,
I also know V.little about the MP3 standard, but I do recall that video
type data is scanned vertically, horizontally and over a number of
frames to eliminate a vast amount of usually repetative data.
If your audio is encoded into this type of data, then it may require a
substantial amount of irelavent processing time to retrieve your audio.
Because the operations are performed on long bit streams (x,y,time), a
standard uC or uP is not really up to performing the task with much
efficiency, a better approach would be to customise a CPLD to perform
the operations on a very wide data bus.
The only application that I can see for a PIC to do the job would be if
you are able to MP3 compress audio only, have limited storage and
maximum data, and are able to use a large ram chip to decode bursts of
realtime audio !
Remember that stuff like MMX is new and not yet available as a microchip
PIC pheripheral. (like A2D, I2C...)
regards,
Graham Daniel.
Sean Breheny wrote:
>
> Hi all,
>
> Since I know almost nothing about the MP3 standard, I am getting in way
> over my head, but I don't see why it wouldn't be possible for a PIC to
> perform almost ANY decoding. It is just an issue of how long it takes to do
> it, and how much storage space it needs to store the results.
<<cut>>
> Sean
--
Steam engines may be out of fashion, but when you consider that an
internal combustion engine would require recovery of waste heat by
transfer just before top dead centre then fashion becomes rather
redundant, USE STRATIFIED HEAT EXCHANGERS ! and external combustion.
You heard it first from: Graham Daniel, managing director of Electronic
Product Enhancements.
Phone NZ 04 387 4347, Fax NZ 04 3874348, Cellular NZ 021 954 196.
ok, someone needs to
figure out how to use a PIC to conntrol it now.... so we can all build
portable MP3 players.... with laptop hard drives of course.
They are using AVR's but I am sure it could be adapted for the PIC (i
think someone is working on it). There is supposed to be an update in the
next little while that will shed more light on the CD/ATAPI interface.
> ok, someone needs to
> figure out how to use a PIC to conntrol it now.... so we can all build
> portable MP3 players.... with laptop hard drives of course.
>
> >Someone asked about MP3 so I did some surfin', and ...
> >
> >An MP3 decoder chip (MPEG1/2 Audio Layer 2/3) :
> >
> > www.intermetall.de/products/mas.html#MAS3507D
> >
> >A PDF datasheet :
> >
> > http://www.intermetall.de/pdf/mas3507d.pdf
> >
> >A place to buy one online (US$34.95) :
> >
> > http://www.multicards.com/100130/order1.htm
> >
> >Long live MP3!
> >
> >Cheers,
> >Brian.
> >-----------------------------------
> >Brian Murray Proximity Pty Ltd
> >http://www.proximity.com.au/~brian/
> >-----------------------------------
>
<< >I'm sorry if this is considered off-topic.
> I was just sitting here wondering if it would be hard to write PIC
>software to decode MP3 songs. can the pic run fast enough to get the
>data from where ever it's stored (a whole separate issue), decompress
>the data, and then convert it to an analog signal(PWM?)? seems like it
>might, but i am relatively new to all this.
> maybe you could use a portable CD player to be the storage medium, or
>a general chassis for portable MP3 player (i know that these already
>exist, just my engineering mind running free here)just a little
>modification there <G>...
>anyways, just curious
>
>thanks,
>Steve K.
>
>P.S. please cc: responses to RemoveMEsk123RemoveMERemoveMEaol.com
>
>______________________________________________________
>Get Your Private, Free Email at http://www.hotmail.com
Sorry, but decoding MP3 requires one heck of a CPU. It pushes a 486dx/4
100 mhz to its upper limits. You might be able to use the PIC to control
some sort of specialized decoder, but a PIC just doesn't have the power to
decode a MP3 by itself. That's MP3 handhelds like the RIO (by Diamond I
think) cost so much... they have a pretty powerful CPU or DSP built in.
Hope I helped. I've been lurking on this list for a while, but have not
said much!
>ok, someone needs to
>figure out how to use a PIC to conntrol it now.... so we can all build
>portable MP3 players.... with laptop hard drives of course.
Or CD-drives... Burn 700 mins of music onto one disk for the car
I am quite aware of grants project.
I have recived help from him in the past dealing with TI-calcul;ator
hardware,
his system used the AVR to access the CD/Hardrive, and scan keypads ect.
but it DOES use a dedicated MP3 ecoder chip.
>Check out http://gussie.alaska.net/acplay/index.spml
>
>They are using AVR's but I am sure it could be adapted for the PIC (i
>think someone is working on it). There is supposed to be an update in the
>next little while that will shed more light on the CD/ATAPI interface.
>
>MD
>
>
>On Wed, 27 Jan 1999, ryan pogge wrote:
>
>> ok, someone needs to
>> figure out how to use a PIC to conntrol it now.... so we can all build
>> portable MP3 players.... with laptop hard drives of course.
>>
>> >Someone asked about MP3 so I did some surfin', and ...
>> >
>> >An MP3 decoder chip (MPEG1/2 Audio Layer 2/3) :
>> >
>> > www.intermetall.de/products/mas.html#MAS3507D
>> >
>> >A PDF datasheet :
>> >
>> > http://www.intermetall.de/pdf/mas3507d.pdf
>> >
>> >A place to buy one online (US$34.95) :
>> >
>> > http://www.multicards.com/100130/order1.htm
>> >
>> >Long live MP3!
>> >
>> >Cheers,
>> >Brian.
>> >-----------------------------------
>> >Brian Murray Proximity Pty Ltd
>> >http://www.proximity.com.au/~brian/
>> >-----------------------------------
>>
I have a player in my car that uses a cd-rom
it is based around a PII 400 system though.
runs linux from a floppy decodes mp3s of the cd-rom
and playes through a SBawe 64 into an amp... then into my speakers...
It uses a pic to scan keypad, and display on LCD screen.
the LCD screen is also connected to the parallel port so that the
song can be shown on the LCD.
>>ok, someone needs to
>>figure out how to use a PIC to conntrol it now.... so we can all build
>>portable MP3 players.... with laptop hard drives of course.
>
>
>Or CD-drives... Burn 700 mins of music onto one disk for the car
>I have a player in my car that uses a cd-rom
>it is based around a PII 400 system though.
>runs linux from a floppy decodes mp3s of the cd-rom
>and playes through a SBawe 64 into an amp... then into my speakers...
>It uses a pic to scan keypad, and display on LCD screen.
>the LCD screen is also connected to the parallel port so that the
>song can be shown on the LCD.
Sony has a beautiful car player with a color LCD display that displays the
song and all. It talks to a 10 disk minidisk changer through some type of
serial cable. Now - if you could make an MP3 player system emulate that 10
disk changer and talk to it with the Sony front end, that would be an
elegant solution!
Some time ago there was a thread about DTMF decoders and one gentleman
stated that he had developed a fully functional DTMF
decoder that used an incredibly small amount of PIC processor resources. He
could not share the details with us because he
had done the work for his employer. I'm sure I know how he did it. I
stumbled on the trick quite by accident while testing
software I wrote for my employer. Since this knowledge is too important to
many PICLIST'ers to keep under my hat, and my
employer is not into telephone products, I'm going to share it with you. I
did a quick experiment to verify the concept
works, and writing the code would be easy, I just don't have the time right
now to work out the numbers related to the DTMF
frequencies. The trick can simultaneously detect any number of frequencies
in almost any amount of noise and interference
with an amazingly small amount of code. The secret is synchronous detection.
For those that don't know, let me first explain and give an example of
synchronous detection. A synchronous detector is a
device (hardware or software) that can detect a signal with a high degree
of noise immunity because it is synchronized
to the source of the signal allowing it to average out noise.
Lets say you had a photoelectric eye as a safety device that stopped a
machine if someone got too close to it. On one
side of the six foot access way to the machine is an LED emitting a beam of
infra-red light in a square wave (very
important) to the receiver 6 ft away. On the other side of the access way
is a receiver which contains a photodiode and
a very high gain amplifier that picked up the square wave from the emitter,
but also electrical and optical interference
from the motor drives of all the machines in the area and the mercury vapor
lights overhead. This interference would cause
the machine to shut down for no apparent reason. The synchronous detector
solves the problem because the square wave driving
the emitting LED also synchronizes the detector, finding the signal and
averaging out the (random) noise.
A synchronous detector works as follows: If a received signal is in phase
with the reference signal, a capacitor is charged
or a counter is incremented. If a signal is received which is out of phase
with the reference signal, a capacitor is dis-
charged or a counter is decremented by an equal amount. The noise, being
random, or just not in step with the reference,
will produce no average charge on the capacitor or count in the counter,
while the real signal will. The amount of noise
immunity is determined by the time constant of the capacitor or the number
of counts in a counter.
A synchronous detector can also be used as a frequency detector if the
number of counts or the time constant is not too long.
In my test, my software synchronous detector running a sample rate of 7KHz
@ 20 samples per test, with a trigger threshold
of 10 counts, would produce an output if an unsynchronized input signal
came within about 50Hz of 7KHz or a multiple thereof.
In a DTMF decoder, you will probably need a low pass filter to keep out
harmonics.
In a frequency detector, you won't be turning on and off an LED, so you
would just test the input and increment a counter
(once or a number of times, depending on required noise immunity and
processor speed) for a period of time each time a
high is seen. You would repeat the process for the same amount of time and
counts, only decrementing the counter each time
a high is seen. The cycle rate of incrementing and decrementing would be
the target trequency. The number of samples and the
trigger threshold (count) would set the bandwidth. Noise would be present
both during the incrementing and decrementing and
would be cancelled (averaged) out.
To similtaneously detect multiple frequencies, you would have one register
for each frequency to be detected, initialized at
the middle of their range. You would run the CPU like a state machine,
looking at the input and incrementing and decrementing
the appropriate registers according the CPU clock rate and the periods of
the various frequencies. After an appropriate
number of counts for the required bandwidth, you would look at each of the
registers and any register that was over the
threshold count would indicate that that particular frequency had been
detected. At this point, you know the rest.
The input to the PIC would be a comparator (no schmitt trigger) or high
gain amplifier like in TV/VCR remote receivers, which
would change state at the zero crossings, saturating with the signal and
clipping off noise. The summing of the two DTMF
frequencies would produce a stream of pulses in which square waves of the
two DTMF frequencies could be seen.
I would like to use this technique in a home project, but I don't have the
time right now to sit down and work out the
numbers related to the DTMF frequencies, although I have verified that the
trick will work. I would be grateful if someone
who does have the time and the need to work out the details would return
the favor and share his/her code with me. I won't
be using it in a commercial project since my employer is not into telephone
products. TTFN :-)
|In a frequency detector, you won't be turning on and off an LED, so you
|would just test the input and increment a counter
|(once or a number of times, depending on required noise immunity and
|processor speed) for a period of time each time a
|high is seen. You would repeat the process for the same amount of time and
|counts, only decrementing the counter each time
|a high is seen. The cycle rate of incrementing and decrementing would be
|the target trequency. The number of samples and the
|trigger threshold (count) would set the bandwidth. Noise would be present
|both during the incrementing and decrementing and
|would be cancelled (averaged) out.
The problem you're apt to run into is that the phase of the input
signal is unknown. Consequently, if you just use a single detector
you'll get a signal that may be anywhere from full-value positive
or full-value negative.
There are two ways around this problem:
[1] Use two or three dectors, whose phases are set either 90 or 120
degrees apart, and use a suitable weighting function to combine
their results.
[2] Use a reference frequency which is "off" by a known amount; this
will cause the output of the detector to produce a wave whose
frequency is the difference between the source and reference
frequencies.
For DTMF dection, [1] is the way to go although most TV's and FM
radios use [2] in their tuning circuits.
Also...for what its worth....Texas Instruments has a new micro, called the
MSP430 (I think), and there is an app note for decoding/encoding DTMF, and
includes source. Didn't spend much time looking at it tho...
> Some time ago there was a thread about DTMF decoders and one gentleman
> stated that he had developed a fully functional DTMF
> decoder that used an incredibly small amount of PIC processor resources. He
> could not share the details with us because he
> had done the work for his employer. I'm sure I know how he did it. I
> stumbled on the trick quite by accident while testing
> software I wrote for my employer. Since this knowledge is too important to
That somebody was probably me. But then again it may've been John Payson
too.
All of the details on HOW to decode dtmf signals is discussed from a
somewhat theoretically perspective on my web page:
But as I like to say, "in theory there's not much difference in theory and
practice, but in practice there is." Believe me, there are several tricks
necessary to implement this theory. And in fact, a robust design even
needs a little bit of extra (low-cost) hardware that's not discussed on
the web page.
I can't release the stuff I've written. However, I know that vertical
counters could be utilized to improve my algorithm. Right now, the
algorithm samples all 8 frequencies in an isochronous 84 instruction cycle
loop. I think the vertical counters can cut this down to 70 cycles (or
less).
>Some time ago there was a thread about DTMF decoders and one gentleman
>stated that he had developed a fully functional DTMF
>decoder that used an incredibly small amount of PIC processor resources. He
>could not share the details with us because he
>had done the work for his employer. I'm sure I know how he did it. I
>stumbled on the trick quite by accident while testing
>software I wrote for my employer.
<snip>
I found the rest of this fascinating and well worth the band width.
But, either I missed something in the description or the author did. How
does he
become synchronized with the input signal in the first place. This
technique sounds like a halfway measure to implementing a phase locked loop
(PLL). With a PLL you lock to the input signal and synthesize a copy of it
with the PLL VCO. The VCO output is the synchronous signal used for
detection. The noise immunity comes from the loop filter which is designed
to respond best to the desired input frequency. Since DTMF tones are not
related harmonically you need a PLL for each tone.
It seems that the scheme actually ignores synchronization. This doesn't
mean that it won't work though. Assuming that the detector and source are
running at exactly the same frequency, the output level will depend on the
phase relationship between the two. The output could be zero if the
relationship is 180 degrees. If the two frequencies are not identical, and
they probably aren't, then the output will beat at the difference. This is
probably the signal he is actually detecting. This also integrates to a
non-zero level, as in the synchronous case, but is dependent on the
capacitor time constant to attenuate out of band frequencies. This will
probably work as long as there is a tuned RC filter for each of the DTMF
tones. Because of the beating there will need to be several cycles of input
and that means that the detection will be slower that is ultimately
possible.
Yes, the author will clear it up for you. The synchronous detector is is
only "synchronous" for a short period of time as the input frequency
is near, but not equal to the sample frequency. Only a certain number of
cycles of the input frequency will increment the counter. The "synchronous
detector" is not really being used as such in this case. By adjusting the
number of samples and the trigger threshold, you can adjust how close to
the sample frequency the input frequency must be in order to trigger the
detector. The low pass filter is the counter. You intentionally adjust the
"low pass filter" (and you can do it with hardware, too) so that the low
frequency beat between the sample and input frequencies will pass through
the filter. I've tested the concept with one test frequency and one
interfering frequency and it worked as I stated earlier. I see no reason
why it would not work with multiple frequencies. I will write the code
myself, test it and post it on the PICLIST as soon as I can find the time.
><Andrew Russell Morris wrote in part>
>
>>Some time ago there was a thread about DTMF decoders and one gentleman
>>stated that he had developed a fully functional DTMF
>>decoder that used an incredibly small amount of PIC processor resources. He
>>could not share the details with us because he
>>had done the work for his employer. I'm sure I know how he did it. I
>>stumbled on the trick quite by accident while testing
>>software I wrote for my employer.
>
> <snip>
>I found the rest of this fascinating and well worth the band width.
>
>But, either I missed something in the description or the author did. How
>does he
>become synchronized with the input signal in the first place. This
>technique sounds like a halfway measure to implementing a phase locked loop
>(PLL). With a PLL you lock to the input signal and synthesize a copy of it
>with the PLL VCO. The VCO output is the synchronous signal used for
>detection. The noise immunity comes from the loop filter which is designed
>to respond best to the desired input frequency. Since DTMF tones are not
>related harmonically you need a PLL for each tone.
>
>It seems that the scheme actually ignores synchronization. This doesn't
>mean that it won't work though. Assuming that the detector and source are
>running at exactly the same frequency, the output level will depend on the
>phase relationship between the two. The output could be zero if the
>relationship is 180 degrees. If the two frequencies are not identical, and
>they probably aren't, then the output will beat at the difference. This is
>probably the signal he is actually detecting. This also integrates to a
>non-zero level, as in the synchronous case, but is dependent on the
>capacitor time constant to attenuate out of band frequencies. This will
>probably work as long as there is a tuned RC filter for each of the DTMF
>tones. Because of the beating there will need to be several cycles of input
>and that means that the detection will be slower that is ultimately
>possible.
>
>Can anyone clear this up for me?
>
>Thanks!
>
>Win Wiencke
>spamImageLogicspam_OUTibm.net
>
>
Without getting into the DTMF stuff, which I have no experience with...
This Synchronous Scheme, sounds a bit like "Tuned Dendrites" so I can
comment safely, from my A.I. background ;)
Essentially, the idea, is that the "Period" of a waveform results in the
waveform PEAKING at certain times.
A counter, that "Counts" the Peaks in relation to a reference signal, is
therefore going to "Count" frequencies that are closer to the reference
signal with a higher value. This is because only those frequencies that
peak near to the reference will peak often enough to get as high a count.
While Higher frequencies, that are "Harmonics" of the original reference
will count as high as the base frequency, using a slightly off frequency
reference, will actually create TWO detectable frequencies, the frequency
of the signal being measured, and the "BEAT" frequency that is the result
of the reference, and the measured frequency, "Interfering" with each
other.
Because higher "Harmonics" have higher beat frequencies, it is possible
to use a slightly off-frequency signal, to detect whether or not the
signal being measured is the frequency required, or some harmonic of it.
Implimentation is pretty reasonable, if you can do the math, to figure out
the period of a particular waveform, then you set your timer to sample
that waveform every so many cycles. If you take two samples a set distance
apart, every so many periods, then the difference between the samples,
will create your beat frequency, which can then be used with a signal
generator, to calibrate the desired beat frequency, in terms of how many
beats on average to expect in the second sample. When both samples match,
your signal is likely to be the correct frequency.
You probably want to use a "Fuzzy" testing proceedure, in order not to
reject signals that are "Close enough" to be merely suffering from noise,
but, this is almost a software PLL in that as long as your signal is
slower than the sample frequency by some margin, you can have fairly good
assurance that the signal once synchronized is not going to drift off
frequency without being detected.
Does anyone have the Windows 98 drivers for an E4 DVD Decoder? I am unable to
download them from the Elecede Technologies site (http://www.e4.com). I believe
that what I need is the CoolDVD software for Win98, version 2.16.
Hi!
I'm working on a project were I need a quadrature decoder to calculate pulses
from an encoder. This should be implemented in a 16C77. I have some idea on20how to implement this but I'm not really intrested to invent the wheel again.20Has
anybody done something like this.
When pin A goes up, pin B state the direction;
If pin B is up, direction is forward, otherwise is backward,
or reversed, but easy as it is.
Wagner.
< Patric Anvegard wrote:
>
> Hi!
> I'm working on a project were I need a quadrature decoder to calculate pulses
> from an encoder. This should be implemented in a 16C77. I have some idea on how to implement this but I'm not really intrested to invent the wheel again. Has
> anybody done something like this.
>
> Patric AnvegŒrd
Wagner Lipnharski wrote:
>
> When pin A goes up, pin B state the direction;
> If pin B is up, direction is forward, otherwise is backward,
> or reversed, but easy as it is.
>
> Wagner.
>
but don' try doing it this way in a industrial enviroment, because of
noise you will get a more random count.
( I had the problem once ) I suggest a state-machine wich
tracks the states of both chanels to filter valid changes of
both channels.
A B
0 0
0 1
1 1
1 0
0 0 -> on count valid in one direction
or:
0 0
1 0
1 1
0 1
0 0 -> on count vaild to the other direction
Hi!
I'm working on a project were I need a quadrature decoder to calculate
pulses
from an encoder. This should be implemented in a 16C77. I have some idea on
how to implement this but I'm not really intrested to invent the wheel
again. Has
anybody done something like this.
Patric AnvegŒrd
----------
The most secure implementation that I have seen is to asynchronously read
the inputs
and use the old (previous) and new readings to determine position value.
The
read rate must be just slightly faster that the maximum change rate on the
inputs.
Reading more often improves the noise immunity.
a new b new A old B old
0 0 0 0 do nothing
0 0 0 1 increment
0 0 1 0 decrement
0 0 1 1 error condition (noise)
0 1 0 0 decrement
0 1 0 1 do nothing
0 1 1 0 error condition (noise )
0 1 1 1 decrement
1 0 0 0 decrement
1 0 0 1 error condition (noise )
1 0 1 0 do nothing
1 0 1 1 increment
1 1 0 0 error condition (noise)
1 1 0 1 decrement
1 1 1 0 increment
1 1 1 1 do nothing
The over sampling makes this relatively noise immune and
old Vs new readings can be implemented in software with
a table or an exclusive or. One of the PC mice I did used table lookup and
processed both axis at once.
Some numbers that are useful for mice design is the fastest measure
hand movement we measured was 43 inches per second
I'm working on a project were I need a quadrature decoder to calculate
pulses
from an encoder.
Patric AnvegŒrd
----------
The most secure implementation that I have seen is to asynchronously
read the inputs and use the old (previous) and new readings to determine
position value.The read rate must be just slightly faster that the maximum
change rate on the inputs.
Reading more often improves the noise immunity.
a new b new A old B old
0 0 0 0 do nothing
0 0 0 1 increment
0 0 1 0 decrement
0 0 1 1 error condition (noise)
0 1 0 0 decrement
0 1 0 1 do nothing
0 1 1 0 error condition (noise )
0 1 1 1 decrement
1 0 0 0 decrement
1 0 0 1 error condition (noise )
1 0 1 0 do nothing
1 0 1 1 increment
1 1 0 0 error condition (noise)
1 1 0 1 decrement
1 1 1 0 increment
1 1 1 1 do nothing
The over sampling makes this relatively noise immune.
Further to the previous post. The following MPC code fragment
will do quadrature decoding. Just keep calling quad whenever your
application has nothing better to do or from the the timer interrupt or
both. It solves both the no motion and error cases.
Hi Stefan, yes, the noisy environment requires more care.
I have heard a lot about noise here and noise there, looks like there is
noise everywhere. hehe :), I understand that, now tell me, a four wire
shielded cable, grounded at the processor side, with the minimum
possible impedance forced on both sides, with some decoupling small
caps, can eliminate a big amount of emi and noises. In some environments
it is necessary some filtering at the AC incoming to the power supply. I
already done that in several situations and *never* got severe noisy
problems, even in metallurgic environments for several different kind of
sensors, with cables longer than 20 ft. The only impossible environment
is the metallurgic electric metal melting chamber... man, if you heard
about EMI that is where it was born... mainly when the electrodes are
pouring thousands of amps over the scrap melting metal and they inject
pure oxygen in the middle of it... do you know that they avoid to use
electronic wrist watches around there? hehe.
Why don't you tell us in which situation, and how the sensor was
connected, cable, filtering, when you got those noise problems?
A lot of people can learn about it if we share our experiences, right?
>
> Hi Wagner,
>
> Wagner Lipnharski wrote:
> >
> > When pin A goes up, pin B state the direction;
> > If pin B is up, direction is forward, otherwise is backward,
> > or reversed, but easy as it is.
> >
> > Wagner.
> >
>
> but don' try doing it this way in a industrial enviroment, because of
> noise you will get a more random count.
>
> ( I had the problem once ) I suggest a state-machine wich
> tracks the states of both chanels to filter valid changes of
> both channels.
>
> A B
> 0 0
> 0 1
> 1 1
> 1 0
> 0 0 -> on count valid in one direction
>
> or:
>
> 0 0
> 1 0
> 1 1
> 0 1
> 0 0 -> on count vaild to the other direction
>
> kind regards,
>
> Stefan Sczekalla-Waldschmidt
> sswTakeThisOuTKILLspamoikossw.de
HP makes an IC that will do it for you, maybe motorola also. You can do it
yourself with 2 flip flops if your processor has an input counter, I've also
done it with an 4 bit up down counter. The counter starts at 8 and counts up
to 15 or down to 0, at either extreme it stops counting. The counter is reset
whenever its polled by the processor.
Wagner Lipnharski wrote:
>
> Hi Stefan, yes, the noisy environment requires more care.
>
> (...)
> is the metallurgic electric metal melting chamber... man, if you heard
> about EMI that is where it was born... mainly when the electrodes are
> pouring thousands of amps over the scrap melting metal and they inject
> pure oxygen in the middle of it... do you know that they avoid to use
> electronic wrist watches around there? hehe.
Well - I visited one while I was still in school. They did aluminium
( Al ) melt there ... The magnetic fields where so strong that you
could hook coins together like a daisy-chain holding only on coin, the
others looked like they where glued to the edge of each other...
>
> Why don't you tell us in which situation, and how the sensor was
> connected, cable, filtering, when you got those noise problems?
The application was a "winch-level( position )-display-and-control"
for 12 winches used in theater
The problems I had, where in with (given) quadratur sensors, mounted to
electrical controled winches. Unfortunately there where several
problems with the assembly I had to migrate my controller. Beside this
- at this time I 've been very new to this kind of enviroment.
( and very unexperienced )
After the first test we discovered that every f***ing relais forces
resets in my circuit. The rack where I had to migrate my system was
build like they never heard about emi. After adding absorber networks
to all relays the system started to work more reliable. but whats this ?
when looking onto the display of the controller - operating one winch
gave also counts to other displays.
operating several winches at once made the system fail.
to make it short,
the winches used "normal closed" magnetic actuated brakes and no
care was taken to emi matters - so the release of a brake triggered
almost everything on every I/O-Port I had ...
but back to the quadratur sensors. The given sensors uses a unbalanced
transmition with an open collector output. the cable length where up to
30 meters, the cable was shilded but laid the same way like the power
cable for the winche.
After the mentioned first test run I reworked the design of the counter
to the full-state-machine-way. this reduced the amount of unwanted
counts
significantly. befor reworking this I used the one chanel-clock
other chanel-data approach. I also did a lot of filtering on the input
lines.
maybe this story is somewhat confuse, and emotional biased -
but if I had used a fully-state-machine design right the first time
for counting the quadratur-encoder pulses, I would have had more
time to discover the problems which where caused by the magnetic brakes.
This project also made it clear to me that working as a freelance
engeneer will cost a lot of nerves sometimes. So I'm now working as
System Administrator and doing "Pic-Ing" as a hobby.
>
> A lot of people can learn about it if we share our experiences, right?
>
> ----------
> The most secure implementation that I have seen is to asynchronously
> read the inputs and use the old (previous) and new readings to determine
> position value.The read rate must be just slightly faster that the maximum
> change rate on the inputs.
>
> Reading more often improves the noise immunity.
>
> a new b new A old B old
> 0 0 0 0 do nothing
> 0 0 0 1 increment
> 0 0 1 0 decrement
> 0 0 1 1 error condition (noise)
> 0 1 0 0 decrement
> 0 1 0 1 do nothing
> 0 1 1 0 error condition (noise )
> 0 1 1 1 decrement
> 1 0 0 0 decrement
> 1 0 0 1 error condition (noise )
> 1 0 1 0 do nothing
> 1 0 1 1 increment
> 1 1 0 0 error condition (noise)
> 1 1 0 1 decrement
> 1 1 1 0 increment
> 1 1 1 1 do nothing
>
> The over sampling makes this relatively noise immune.
>
Are you sure about the Table ???
There are five times decrement and only three times increment to see.
But the general idea is very similar the way I did exception -
by loosing some of the resolution I did the state-machine in
this way, that only after running through the whole sequence
00:01:11:10:00 OR 00:10:11:01:00 a up or down count was done.
I've posted this little routine several times before in the list, and got no
comments. I've used it to read a hand-operated encoder (volume in a piped
music application) with no problem. Yes, this is not a very noisy
environment...
Here it goes:
Assume the actual state of the encoder is in 'encod' bits 0 and 1.
; Encoder read
clrf auxint
movf auxint,W ; encod <- (actual state) xor (previous one)
xorwf encod,F ; (only bits 0 and 1 affected)
;
rrf auxint,F ; XOR results, reordered, get
rlf encod,F ; into encod, in bits 0 and 1.
rrf auxint,F ; This bits are the motion indicators
rlf encod,F
;
btfsc encod,2 ; 'X' motion...
incf posenc,F
btfsc encod,3 ; ...or 'Y'
decf posenc,F
That's all. You have the "position" of the encoder in posenc. I need only 8
bits, but this is your choice. It is very easy to get 16 or more bits.
If you want some kind of soft filtering, previous "motion detection" of the
encoder are in 'encod', bits 4-5 and 6-7, in the same 2-3 fashion (you have
the last 3 readings). This bits mean:
3 2
--- ---
0 0 -> No motion
0 1 -> X motion
1 0 -> Y motion
1 1 -> Error
The last state indicates there is an error. It may be some kind of noise, or
it can be too lazy readings of the encoder... you have to read it more
often.
This routine uses 'encod', 'posenc' and 'aux', and lasts 11
instuction-cycles EVERY TIME. I placed it in a timer-interrupted routine,
where other tasks are taken.
Thats all. Hope my english is not too bad, and hope this helps.
>When pin A goes up, pin B state the direction;
>If pin B is up, direction is forward, otherwise is backward,
>or reversed, but easy as it is.
>
>Wagner.
>
>< Patric Anvegard wrote:
>>
>> Hi!
>> I'm working on a project were I need a quadrature decoder to calculate
pulses
>> from an encoder. This should be implemented in a 16C77. I have some idea
on how to implement this but I'm not really intrested to invent the wheel
again. Has
>> anybody done something like this.
>>
>> Patric AnvegŒrd
>
The one and only problem you have to account for is that the resting
position of the decoder is VERY close the the leading edge of one of the
pulses.. ie if you bump the decoder slightly or it begins to wear, it would
be all too possible to generate direction-indication pulses in one direction
without even touching the knob..
Believe me, I know :) I did a durability test with one by chucking it into a
reversible drill! After all was said and done, it was sloppy and generating
errors.. So, anyway, to get around this, I had the processor read one input,
then look at the other for direction, THEN wait for them BOTH to be high
before generating an output pulse, because only with that sequence of events
can you be sure the person actually wanted the pulse output. If it gets
direction data and it takes more than .5 sec for A*B=1, it times out and
ignores the direction data as an error...
This is the only sure way of doing it.
Thanks for the good advises to solve my problem with the quadrature decoding.
I'll try some of the routines I got from Walter Banks and Alvaro and see how they work...
The solution that I had some thoughts about before I sent this message to the
list
was that this problem could be solved by having one of the channels(A) connected
to the Capture input and the other one to an "ordinary" input.
The Capture module is initialized to interrupt on rising edge. When I get an0interrupt I
put the processor in "state 1" if the B-channel is 1 or in "state 0" if the B-channel is 0
and when changes the CCP module to interrupt on falling edge.
When I get the next interrupt I read the B channel and detects the direction.20If the
previous state was 0 I should now get a 1 on the B-channel or if the previous state was 0 I should now get a 0. If I get two 0 states (or two 1 states) I ignore0it (this could
accure if I get noise on the A channel or if the direction has changed on the encoder.
Does anyone have an argument why this should'nt work or should I put some effort to try this solution too.
Thanks for the good advises to solve my problem with the quadrature decoding.
I'll try some of the routines I got from Walter Banks and Alvaro and see how they work...
The solution that I had some thoughts about before I sent this message to the
list
was that this problem could be solved by having one of the channels(A) connected
to the Capture input and the other one to an "ordinary" input.
The Capture module is initialized to interrupt on rising edge. When I get an0interrupt I
put the processor in "state 1" if the B-channel is 1 or in "state 0" if the B-channel is 0
and when changes the CCP module to interrupt on falling edge.
When I get the next interrupt I read the B channel and detects the direction.20If the
previous state was 0 I should now get a 1 on the B-channel or if the previous state was 0 I should now get a 0. If I get two 0 states (or two 1 states) I ignore0it (this could
accure if I get noise on the A channel or if the direction has changed on the encoder.
Does anyone have an argument why this should'nt work or should I put some effort to try this solution too.
Thanks for the good advises to solve my problem with the quadrature decoding.
I'll try some of the routines I got from Walter Banks and Alvaro and see how they work...
The solution that I had some thoughts about before I sent this message to the
list
was that this problem could be solved by having one of the channels(A) connected
to the Capture input and the other one to an "ordinary" input.
The Capture module is initialized to interrupt on rising edge. When I get an0interrupt I
put the processor in "state 1" if the B-channel is 1 or in "state 0" if the B-channel is 0
and when changes the CCP module to interrupt on falling edge.
When I get the next interrupt I read the B channel and detects the direction.20If the
previous state was 0 I should now get a 1 on the B-channel or if the previous state was 0 I should now get a 0. If I get two 0 states (or two 1 states) I ignore0it (this could
accure if I get noise on the A channel or if the direction has changed on the encoder.
Does anyone have an argument why this should'nt work or should I put some effort to try this solution too.
Thanks for the good advises to solve my problem with the quadrature decoding.
I'll try some of the routines I got from Walter Banks and Alvaro and see how they work...
The solution that I had some thoughts about before I sent this message to the
list
was that this problem could be solved by having one of the channels(A) connected
to the Capture input and the other one to an "ordinary" input.
The Capture module is initialized to interrupt on rising edge. When I get an0interrupt I
put the processor in "state 1" if the B-channel is 1 or in "state 0" if the B-channel is 0
and when changes the CCP module to interrupt on falling edge.
When I get the next interrupt I read the B channel and detects the direction.20If the
previous state was 0 I should now get a 1 on the B-channel or if the previous state was 0 I should now get a 0. If I get two 0 states (or two 1 states) I ignore0it (this could
accure if I get noise on the A channel or if the direction has changed on the encoder.
Does anyone have an argument why this should'nt work or should I put some effort to try this solution too.
Thanks for the good advises to solve my problem with the quadrature decoding.
I'll try some of the routines I got from Walter Banks and Alvaro and see how they work...
The solution that I had some thoughts about before I sent this message to the
list
was that this problem could be solved by having one of the channels(A) connected
to the Capture input and the other one to an "ordinary" input.
The Capture module is initialized to interrupt on rising edge. When I get an0interrupt I
put the processor in "state 1" if the B-channel is 1 or in "state 0" if the B-channel is 0
and when changes the CCP module to interrupt on falling edge.
When I get the next interrupt I read the B channel and detects the direction.20If the
previous state was 0 I should now get a 1 on the B-channel or if the previous state was 0 I should now get a 0. If I get two 0 states (or two 1 states) I ignore0it (this could
accure if I get noise on the A channel or if the direction has changed on the encoder.
Does anyone have an argument why this should'nt work or should I put some effort to try this solution too.
Thanks for the good advises to solve my problem with the quadrature decoding.
I'll try some of the routines I got from Walter Banks and Alvaro and see how they work...
The solution that I had some thoughts about before I sent this message to the
list
was that this problem could be solved by having one of the channels(A) connected
to the Capture input and the other one to an "ordinary" input.
The Capture module is initialized to interrupt on rising edge. When I get an0interrupt I
put the processor in "state 1" if the B-channel is 1 or in "state 0" if the B-channel is 0
and when changes the CCP module to interrupt on falling edge.
When I get the next interrupt I read the B channel and detects the direction.20If the
previous state was 0 I should now get a 1 on the B-channel or if the previous state was 0 I should now get a 0. If I get two 0 states (or two 1 states) I ignore0it (this could
accure if I get noise on the A channel or if the direction has changed on the encoder.
Does anyone have an argument why this should'nt work or should I put some effort to try this solution too.
The decoder I used (Bournes) had a specified contact bounce time of 5 ms.
That was a good reason not to connect it a an interupt pin! Seriously I did
think about thihs method and was warned against it by someone else on the
list becuase of this. I guess if you are using a super optical encoder with
no bounce it would be ok.
A point I missed making in my earlier comments on
quadrature decoding is that electrical noise is generally not
a serious problem. The leads to the sensors are generally
short and generally quite low inpedence.
Mechanical noise is for the most part self correcting in
the code that I posted. Even the apparent jitter of the
edge of a transistion is completely self correcting with
the apparent short term error of one count and no
system accumulated error.
The decoder I used (Bournes) had a specified contact bounce time of 5 ms.
That was a good reason not to connect it a an interupt pin! Seriously I
did
think about thihs method and was warned against it by someone else on the
list becuase of this. I guess if you are using a super optical encoder
with
no bounce it would be ok.
|The one and only problem you have to account for is that the resting
|position of the decoder is VERY close the the leading edge of one of the
|pulses.. ie if you bump the decoder slightly or it begins to wear, it would
|be all too possible to generate direction-indication pulses in one direction
|without even touching the knob..
What about regarding the four states of the encoder as (in CW order),
1X, X0, 0X, and X1? Or, to put it another way...
State 0:
Wait for first input lo.
If second input lo, inc count and goto state 1. Else dec and state 3.
State 1:
Wait for second input hi.
If first input lo, inc count and goto state 2. Else dec and state 0.
State 2:
Wait for first input hi.
If second input hi, inc count and goto state 3. Else dec and state 1.
State 3:
Wait for second input lo.
If first input hi, inc count and goto state 0. Else dec and state 2.
Note that since this algorithm will always be waiting for an edge on the
input which *DIDN'T* change last, it won't have jitter problems the way
the more "normal" algorithm doesn. Further, if the chip being used has
suitably-programmable interrupts, the decoding can be interrupt-driven
without excessive numbers of interrupts.
I can't really see why this problem should accure.......
Or maybe I did'nt explain too well what I mean.
Lets call the two channels "Count" and "Direction"
The "Count" is always interrupted on change with the
capture-input. It the last interrupt was on falling edge
the next must be on rising edge. The "direction" is neverconnected to an interrupt. So if I'm very close to the "Direction"
leading edge I would not get any interrupt (ever). If I'm very close to the "Count" leading edge the following would appear:
1. I get an interrupt (on rising edge on "Counter").
2. I read the "Direction"-input and detects if it's high or low.
3. I get an interrupt (on falling edge on "Counter")
4. I read the "Direction"-input and detects that i has not changed
since 2 and then I don't count up or down.
To get a faulty count the resting position has to be very close
to both the "Direction" and the "Count" leading edge.....
|The one and only problem you have to account for is that the resting
|position of the decoder is VERY close the the leading edge of one of the
|pulses.. ie if you bump the decoder slightly or it begins to wear, it would
|be all too possible to generate direction-indication pulses in one direction
|without even touching the knob..
What about regarding the four states of the encoder as (in CW order),
1X, X0, 0X, and X1? Or, to put it another way...
State 0:
Wait for first input lo.
If second input lo, inc count and goto state 1. Else dec and state 3.
State 1:
Wait for second input hi.
If first input lo, inc count and goto state 2. Else dec and state 0.
State 2:
Wait for first input hi.
If second input hi, inc count and goto state 3. Else dec and state 1.
State 3:
Wait for second input lo.
If first input hi, inc count and goto state 0. Else dec and state 2.
Note that since this algorithm will always be waiting for an edge on the
input which *DIDN'T* change last, it won't have jitter problems the way
the more "normal" algorithm doesn. Further, if the chip being used has
suitably-programmable interrupts, the decoding can be interrupt-driven
without excessive numbers of interrupts.
Yes, you're quite right. You have clarified that you are looking at
*both* edges of the "clock" (interrupt) phase. The problem comes when
this is not understood and someone attempts to simplify it by using only
*one* edge.
The whole system (*any* quadrature encoder) depends on the ability of
the firmware to respond to a transition on one phase (and that includes
bounces) before any transition occurs on the other.
Also, any encoder in which the bounce of one phase can ever extend to
the subsequent transition on the other would be essentially useless in
consequence.
"Mechanical" encoders (contacts) are thus limited to non-critical uses
such as manual adjustment knobs. All my mice with PCB encoder discs are
now in the "curiousity" box (I can't bring myself to throw anything
out...).
The chief limitation of "count" and "direction" encoding is that it
halves the resolution, i.e., you can only respond to transitions on the
"count" phase. Better is to XOR the two inputs and feed that to the
IRQ input (which still must detect both transitions).
I like John Payson's suggestion which is a two-phase debounce.
--
Cheers,
Paul B.
Use synchronous detection software to eliminate noise sensitivity. I've
done this to eliminate motor noise pickup from a homemade shaft encoder. It
completely solved the problem. Mine was an incremental encoder (did not
sense direction) but two photodetectors and synchrounous detectors will be
required for quadrature detection. I can't give you my code, since it
belongs to my employer, but I'll tell you a little about how a synchronous
detector works.
Preset two registers to the middle of their range (128, probably). Write
your software to pulse the photodetector LEDs at different times, reading
the detectors such that you increment the appropriate counter when the
emitter associated with that counter is on, and decrement the counter when
the associated emitter is off. Any noise or non-synchronous signals will be
virtually cancelled out. Set your trigger threshold to half the total
number of counts for each photodetector for max noise immunity. You don't
need a lot of counts for excellent noise immunity. Experiment. More counts
slows you down. Don't set your count number so high that it is possible to
overflow or underflow the registers. You don't necessarily need a square
wave at the emitters as long as you take the same number of samples while
the LED is on as when it's off. Then, use the quadrature detection ideas of
other respondants to realize a noise free quadrature decoder.
I hopes this helps. It worked beautifully for me.
At 12:10 PM 4/20/99 +0000, you wrote:
>Hi everybody!
>
>Thanks for the good advises to solve my problem with the quadrature decoding.
>I'll try some of the routines I got from Walter Banks and Alvaro and see
how they work...
>
>The solution that I had some thoughts about before I sent this message to
the list
>was that this problem could be solved by having one of the channels(A)
connected
>to the Capture input and the other one to an "ordinary" input.
>The Capture module is initialized to interrupt on rising edge. When I get
an interrupt I
>put the processor in "state 1" if the B-channel is 1 or in "state 0" if
the B-channel is 0
>and when changes the CCP module to interrupt on falling edge.
>When I get the next interrupt I read the B channel and detects the
direction. If the
> previous state was 0 I should now get a 1 on the B-channel or if the
previous state was 0 I should now get a 0. If I get two 0 states (or two 1
states) I ignore it (this could
> accure if I get noise on the A channel or if the direction has changed on
the encoder.
>
>Does anyone have an argument why this should'nt work or should I put some
effort to try this solution too.
>
>Patric AnvegŒrd
>
>
I am working on a dtmf decoder for a school project. I was wondering if
anyone could help me write a well documented program for the 12C672 it is an
8 DIP package and I am using the holtek HT9170 which uses a four pin binary
output. (output described below) Does anyone know a good LCD to use?
Thanks,
Robert Szasz EraseMERszasz.....pay.net
digit pin a pin3 pin2 pin1 pin0
1 H L L L H
2 H L L H L
3 H L L H H
4 H L H L L
5 H L H L H
6 H L H H L
7 H L H H H
8 H H L L L
9 H H L L H
0 H H L H L
# H H L H H
* H H H L L
a H H H L H
b H H H H L
c H H H H H
d H L L L L
- L - - - -
Looks like you've used 5 of your pins already, add power and ground and that
gives you just 1 pin left. You could use this to drive a serial LCD
display, or use it to gate the /OE pin on the decoder which means you can
use the 5 signal pins for something. Unfortunately even driving a normal
LCD in 4 bit mode needs 6 pins, so that may not help you much, unless you
expand the I/O by using a shift register, which is probably the best option.
Are you forced to use an 8 pin PIC? It would have been easier to use the
16F84 with it's higher pin count.
> I am working on a dtmf decoder for a school project. I was wondering if
> anyone could help me write a well documented program for the 12C672 it is an
> 8 DIP package and I am using the holtek HT9170 which uses a four pin binary
> output. (output described below) Does anyone know a good LCD to use?
> Thanks,
> Robert Szasz
> spamRszaszKILLspam@spam@pay.net
>
> digit pin a pin3 pin2 pin1 pin0
> 1 H L L L H
> 2 H L L H L
> 3 H L L H H
> 4 H L H L L
> 5 H L H L H
> 6 H L H H L
> 7 H L H H H
> 8 H H L L L
> 9 H H L L H
> 0 H H L H L
> # H H L H H
> * H H H L L
> a H H H L H
> b H H H H L
> c H H H H H
> d H L L L L
> - L - - - -
--
=================================================
For Embedded Controls Solutions and Custom Designs
CHIP TECHNOLOGIES - Member, Microchip Consultant Program
Bangalore - INDIA
On Tue, 4 May 1999 23:44:03 -0700 Robert Szasz <RemoveMErszaszRemoveMEPALY.NET> writes:
>I am working on a dtmf decoder for a school project. I was wondering
>if
>anyone could help me write a well documented program for the 12C672 it
>
Since only 6 of the pins of an 8 pin PIC are used for I/O, this project
will quickly run out of pins. It is likely that several tricks and maybe
some extra hardware would be needed to interface both the DTMF decoder
and an LCD. Going to an 18-pin PIC would simplify things a lot.
As for converting the 4-bit codes to ASCII characters to display, just
use a 16-entry table. Put the binary outputs in order from LLLL to HHHH
and write the corresponding ASCII into the table. The output from this
chip looks like that from an 8870, in that case the conversion table
would be:
dt 'D1234567890#*ABC'
To display a tone, read the 4-bit code from the DTMF chip and use it as
an index from 0 to 15 into the table. Retrieve the corresponding ASCII
code from the table and send it to the LCD.
Is the HT9170 pin-compatible with the MT8870? I have a project which
uses the latter chip but it is hard to find.
___________________________________________________________________
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 a final project for my college. I plan to detect dtmf signal from
telephone to be decoded. I use PIC 16F84. And I have some
possibilities/theorys. Using interrupt and counter together or counter
only
or ADC 1bit (or 8 bit ADC).
I think I need some literatures, and many thanks if you can give me some
references that I can download. Which one is better for above theorys ?
Or
do you have any advise or some example program ?
I assume that you are trying to do it with signal processing because it's
for school??? If all you want to do is detect the DTMF, you do know there
are chips for that, right!?
YES Try the Mitel MT8870CE. 4 bit binary output, Data Valid, Built in
Filters AND input preamp
At 11:12 PM 7/13/99 -0400, you wrote:
>I assume that you are trying to do it with signal processing because it's
>for school??? If all you want to do is detect the DTMF, you do know there
>are chips for that, right!?
>
>-Steve
>
>{Original Message removed}
If you want to do the DTMF decoding yourself, there was a detailed
discussion about this on the list a while ago. Check the archives on http://www.i.can't.remember
Can someone help me please.
> Hi,
>
> I have a final project for my college. I plan to detect dtmf signal from
>
> telephone to be decoded. I use PIC 16F84. And I have some
> possibilities/theorys. Using interrupt and counter together or counter
> only
> or ADC 1bit (or 8 bit ADC).
>
> I think I need some literatures, and many thanks if you can give me some
>
> references that I can download. Which one is better for above theorys ?
> Or
> do you have any advise or some example program ?
>
> Thank you very much for your help.
>
>
> Best Regards,
>
> Harry Febianto
>
>
Steve Ridley wrote:
>
> Hi Harry
>
> If you want to do the DTMF decoding yourself, there was a detailed
> discussion about this on the list a while ago. Check the archives on
> http://www.i.can't.remember
> Can someone help me please.
>
> Steve
>
> Hi,
>
> I have a final project for my college. I plan to detect dtmf signal from
>
> telephone to be decoded. I use PIC 16F84. And I have some
> possibilities/theorys. Using interrupt and counter together or counter
> only
> or ADC 1bit (or 8 bit ADC).
>
> I think I need some literatures, and many thanks if you can give me some
>
> references that I can download. Which one is better for above theorys ?
> Or
> do you have any advise or some example program ?
>
> Thank you very much for your help.
>
> Best Regards,
>
> Harry Febianto
As others have already said, using a dedicated DTMF decoder IC is the
preferred way to decode DTMF. But..., if you're somewhat demented like
myself then take a look at:
The effort to make things like that, using a microcontroller and
software to decode DTMF is 100% valid upon the point of view of learning
things, but for the sake of functionality just use dedicated microchips
to do the job, they were done with much more knowledge and it will saves
your time and money. It is the same to build up a microcontroler using
TTL discrete chips... imagine the board size and problems...
educationally, or school projects speaking it is fantastic... but that's
all. There are several DTMF decoders available for less than $2. Your
school project could be the one to read the chip, display the numbers,
store them, and so on, not the decoding itself...
>
> Harry Febianto wrote:
> >
> > Hi,
> >
> > I have a final project for my college. I plan to detect dtmf signal from
> >
> > telephone to be decoded. I use PIC 16F84. And I have some
> > possibilities/theorys. Using interrupt and counter together or counter
> > only
> > or ADC 1bit (or 8 bit ADC).
> >
> > I think I need some literatures, and many thanks if you can give me some
> >
> > references that I can download. Which one is better for above theorys ?
> > Or
> > do you have any advise or some example program ?
> >
> > Thank you very much for your help.
> >
> > Best Regards,
> >
> > Harry Febianto
>
> As others have already said, using a dedicated DTMF decoder IC is the
> preferred way to decode DTMF. But..., if you're somewhat demented like
> myself then take a look at:
>
> http://www.interstice.com/~sdattalo/technical/theory/dtmf.html
>
> As I've said in previous posts on this subject: this algorithm works
> well, but additional analog signal processing is required to make it
> robust.
>
> Scott
I need to build the multiplexed alphanumeric LED display with 10 digits. I
will use 16 segment LED with common anode. I would like to ask you, if you
have any idea if there is some simple 16 segment decoder chip available
(like 74LS247 for 7 segment) ?
If no, I will need to use bigger PIC :-(((
Best regards
PavelK
**************************************************************************
* Pavel KorenskyÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊ *
* DATOR3 LAN Services spol. s r.o.ÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊ *
* Styblova 13, 140 00, Prague 4, Czech Republic ÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊ *
*ÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊ *
* PGP Key fingerprint:Ê F3 E1 AE BC 34 18 CB A6Ê CC D0 DA 9E 79 03 41 D4 *
*ÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊ *
* SUMMA SCIENTIA - NIHIL SCIREÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊ *
**************************************************************************
> Van: Pavel Korensky <TakeThisOuTpavelk@spam@@spam@DATOR3.ANET.CZ>
> Aan: TakeThisOuTPICLISTspamMITVMA.MIT.EDU
> Onderwerp: Decoder for 16 segment LEDs ?
> Datum: dinsdag 17 augustus 1999 13:22
>
> Hello,
>
> I need to build the multiplexed alphanumeric LED display with 10 digits.
I
> will use 16 segment LED with common anode. I would like to ask you, if
you
> have any idea if there is some simple 16 segment decoder chip available
> (like 74LS247 for 7 segment) ?
> If no, I will need to use bigger PIC :-(((
Hello Pavel, I suspect you will be multiplexing the 10 display's ... You
could multiplex your segments as 2*8 too ... with 1-to-2 decoders, or
simply by two bus-drivers ...
There are numerous LED driving ICs around. An oldie but a goodie is the
MM545X family which drives about 32 segments (40 pin dip) and has large
current drive capability, segment current control, doesn't need segment
resistors and has a very simple 2 wire serial interface which can be easily
driven from a PIC or whatever. For over 32 segments you can use more of
these :-) or could multiplex them under software control.This makes the PIC
a little busier but is still easy enough to do. Using one segment per
MM545X output the operation is fully static with no software overhead once
the data is output.
> Pavel,
>
> There are numerous LED driving ICs around. An oldie but a goodie is the
> MM545X family which drives about 32 segments (40 pin dip) and has large
> current drive capability, segment current control, doesn't need segment
> resistors and has a very simple 2 wire serial interface [...]
here's a (little) more info:
The MM54X chips are from Micrel -- I found the MM5450 and MM5451.
I'm using the mm5450 of Micrel with a Pic16c84 and it works great!.
I'm displaying 3 1/2 digits for a clock counter (12:00-00:00) and other
second counter for seconds (30-00) , using 33 of the available pins and
the last one is for a sound in a speaker or something like that...
if you want to use for 16 led segments, may be you must multiplex
it, using one mm5450 to drive 4 16-segments leds (using the first 32 bits
for 1-16 common entries (common anode) and the last 2 bits to multiplex
the transistors that will be used in the anode. (4 transistors with a
combination 00,01,10,00, for activate each one)..
The clock time is about 0.5 Mhz, enough to multiplex several digits..
and using 1 MM5450 you just use 2 pins in the pic if you want other, just
use another pin for data and the clock as common.
> On Wed, 18 Aug 1999, Russell McMahon wrote:
>
> > Pavel,
> >
> > There are numerous LED driving ICs around. An oldie but a goodie is the
> > MM545X family which drives about 32 segments (40 pin dip) and has large
> > current drive capability, segment current control, doesn't need segment
> > resistors and has a very simple 2 wire serial interface [...]
>
> here's a (little) more info:
>
> The MM54X chips are from Micrel -- I found the MM5450 and MM5451.
>
> My new best friend QuestLink.com has more information:
> http://www.questlink.com/Index/Listing/0,1121,0_0_183100,00.html
>
>
> - j
>
I'm interested with to design a DTMF decoder using a PIC. I can
do that with a DSP chip, but I think if it is possible to do it
using a micro controller, that will be better. Do you know any
site, I can find any valuable information about to design a
DTMF decoder using a PIC.
> Hellow
>
> I'm interested with to design a DTMF decoder using a PIC. I can
> do that with a DSP chip, but I think if it is possible to do it
> using a micro controller, that will be better. Do you know any
> site, I can find any valuable information about to design a
> DTMF decoder using a PIC.
>
> Thanks
>
> Ozgur
>
>
Check Electronics Now magazine about a year or two ago.
There was an article there addressing this very thing.
You can get the source code for the PC from their website
at http://www.gernsback.com. It might have been Popular Electronics,
but I believe it was Electronics Now. Actually, it doesn't
matter since both magazines are under the same website.
rta.nsw.gov.au
