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

Truncated match.
PICList Thread
'serial transmission and receiving.'
1997\11\01@232920 by JOSE ANTONIO CHONG LEAL

flavicon
face
Hi ya all,

im trying to make a little IR control bot with PIC's, it would have 2
motors each one with FWD and REV. im going to use the 40 KHz IR Modules.

this is my first attempt at a serial transmission project.

since i only have 4 things to make (right motor fwd and rev and left motor
fwd and rev)
i can use a nibble of data. if something is to be activated it would
generate a "1".

im planning to use a continuos loop in the transmitter, so it would send
the byte over and over again, and the transmitter would catch the byte and
do whatever it has activated.

but how do i make the receiver recognize the start bit and stop bit????

the transmitter would have either a 71 and the receiver a '84 or vice
versa, what configuration would be best???

i have an old 16B (not 16B1). an only familiar to micorchip, no parallax
code.
any suggestions???tips????............

later, take care.....SALUD!!

1997\11\02@125534 by Alec Myers

flavicon
face
>
>im planning to use a continuos loop in the transmitter, so it would send
>the byte over and over again, and the transmitter would catch the byte and
>do whatever it has activated.
>
>but how do i make the receiver recognize the start bit and stop bit????
>

Basically, the receiver sits waiting for a (say) falling edge. That
indicates the start bit, and thereafter the receiver samples the input port
periodically for the length of time to grab one byte. If the last bit
(where the stop bit should be) is received as high, then you (may) have a
good byte - otherwise your receiver was triggered by a glitch, or in the
middle of a byte.

As long as the transmitter pauses occasionally, for longer than one byte's
transmission time, the receiver will finish its sequence and be in a state
of looking for the start bit's falling edge. So the next falling edge from
the transmitter (start bit) will be picked up as such by the receiver, and
the two will be in synch.

Actually, you probably ought to consider a bit-level coding scheme, such as
Manchester coding. To transmit a 1 bit you send 10, and to transmit a 0
bit, you send 01. So the byte 11011011 goes out as 1010011010011010. It
halves the data rate, but you can pick up errors much more easily.
Obviously, if the receiver gets more than two 1's or 0's in a row, there's
an error.

Then you can deliberately transmit an 'illegal' signal -such as 11110000 -
which causes an error in the receiver and allows you to reset.  You know
the data that follows is the start of a new byte.

And you can easily tell the difference between 'line-idle' and 'line-dead'.
The former gives you ...0101010101010.... and the latter probably all sorts
of random stuff.

There are other advantages to this kind of coding, too - some
communications channels don't like long strings of 000's or 111's, because
they drift off frequency (or whatever). So you may _need_ to use some kind
of coding system.

If you just want to start off with a simple serial link (no coding) you can
use the UART on the '84 as the receiver, and write a simple bit-bashing
routing on the '71 as a transmitter. It's simpler to write transmitter code
from scratch than receiver. The UART in the PIC will sort out all the start
and stop bits, as long as you transmit them right.

Don't forget to include lots of redundancy in the codes - transmit each
nibble at least twice, and compare them.


Good Luck

Alec

__________________________________________________________________________
                                ________       W5 Ltd.
                               / ______/
______        ______        _ / /___           33 Sneath Avenue
\     \      /      \      / /____  \          London NW11 9AJ
 \     \    /        \    /  __  /  /          United Kingdom
  \     \  /          \  /  / /_/  /
   \     \/     /\     \/   \_____/            Telephone +44 181 922 7778
    \          /  \           /                Fax       +44 976 650 110
     \        /    \         /                 eMail     spam_OUTmailTakeThisOuTspamW5.co.uk
      \______/      \_______/
Technology * Innovation * Design * Solutions
__________________________________________________________________________

1997\11\02@164632 by Mike Keitz

picon face
>>im planning to use a continuos loop in the transmitter, so it would
>send
>>the byte over and over again, and the transmitter would catch the
>byte and
>>do whatever it has activated.

Infrared remote-control links in consumer equipment usually use a 40 KHz
carrier and pulse-width modulation.  It's a good idea to use this sort of
scheme if possible since the most complicated part, the light detector
and analog signal processing in the receiver, is available as a low-cost
module.  Also, pushbutton- operated transmitters can be purchased off the
shelf.  Throughput of about 500-1000 baud and range on the order of 10
meters is possible.

The receiver processes the signal from the photodiode through a bandpass
filter and level detector.  When the level of 40 KHz energy is
sufficiently high, the digital output (usually active-low) turns on.  At
the transmitter, the LED is turned on and off at a 40 KHz rate (50% duty
cycle).  To send a bit, make a dropout of a few hundred us.  If the
dropout is close to the last one, call the bit a 1, if it is far, call it
a zero.  The start bit is a long time with no dropout.  For example, to
send 1101, transmit:

111111111111101110111011111101110
^-start------^   1   1      0   1

After the sequence leave the LED off for a while (depending on how long
the batteries in the transmitter need to last), and then repeat.  The
AM/AGC circuit in the receiver rejects noise best when the transmitter's
average power (inside the block) is high.  This is why long on times and
short off times are used.  When no signal is recieved most of the
reciever modules will output occasional short noise pulses, which the
start pulse detection logic immediately rejects.

The effective bit rate varies with the content of the data.  This is
usually not a problem.  The block rate needs to be defined for the worst
case data.  Some systems send the data both normal, then inverted, in the
block.  This makes the blocks constant length as well as providing some
redundancy.  If the response time can be slow (for example, pressing
buttons on a remote control), use a lot of redundancy: for example
receive 3 blocks and take action only if all 3 are the same.

>>
>>but how do i make the receiver recognize the start bit and stop
>bit????

A receiver for this type of code could be built around a routine that
measures how long the IR stays on:
  wait till IR on
  measure time
  wait till IR off
The result would be classed into 3 times: very long -> start bit, long ->
0 bit, short -> 1 bit.  It would also be good to time out the "wait till
IR on" and if it is longer than specified, reject the whole block and go
back to waiting for a start bit.

The core of the transmitter software would be a simple "send N cycles of
40 KHz" routine coupled with a routine to shift through the bits and call
the sending with one of 3 values of N.

Integrating the IR recption with the PIC's other duties can be done  in
various ways, but it does make it more complicated.  The IR receiver
module could be connected to the INT input, or a timer interrupt
state-machine polling of the IR input implemented.  Start with simple
software timing until you're able to make that work.

1997\11\02@191830 by Andrew Warren

face
flavicon
face
JOSE ANTONIO CHONG LEAL <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU> wrote:

> since i only have 4 things to make (right motor fwd and rev and left
> motor fwd and rev) i can use a nibble of data. if something is to be
> activated it would generate a "1".

Jose:

Since "forward" and "reverse" are mutually exclusive, you don't need
four bits... If you use "0" for "reverse" and "1" for "forward", you
can send the whole message in only TWO bits.

-Andy

=== Andrew Warren - fastfwdspamKILLspamix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499

1997\11\02@195327 by Felix Centeno

flavicon
face
part 0 1724 bytes
head>

if it is a serial transmition , why you dont'n use
a chip like 74vhc943 to manage the output/input
signals from PICs ?

----------
> From: JOSE ANTONIO CHONG LEAL <antonio@TELNOR.NET>
> To: PICLIST@MITVMA.MIT.EDU
> Subject: serial transmission and receiving.
> Date: Domingo 2 de Noviembre de 1997 12:24 AM
>
> Hi ya all,
>
> im trying to make a little IR control bot with PIC's, it would have 2
> motors each one with FWD and REV. im going to use the 40 KHz IR Modules.
>
> this is my first attempt at a serial transmission project.
>
> since i only have 4 things to make (right motor fwd and rev and left motor
> fwd and rev)
> i can use a nibble of data. if something is to be activated it would
> generate a "1".
>
> im planning to use a continuos loop in the transmitter, so it would send
> the byte over and over again, and the transmitter would catch the byte and
> do whatever it has activated.
>
> but how do i make the receiver recognize the start bit and stop bit????
>
> the transmitter would have either a 71 and the receiver a '84 or vice
> versa, what configuration would be best???
>
> i have an old 16B (not 16B1). an only familiar to micorchip, no parallax
> code.
> any suggestions???tips????............
>
> later, take care.....SALUD!!

1997\11\03@123434 by Steve Smith
picon face
Since "forward" and "reverse" are mutually exclusive, you don't need
four bits... If you use "0" for "reverse" and "1" for "forward", you
can send the whole message in only TWO bits.

-Andy

Andy I think that maybe Stop maybe a good condition unless the object is to
be in motion ad infinitum. This blows away the mutually exclusive theroy.

maybe 00 for stop 01 for foward 10 for backwards and 11 for bad code !
a similar response for L+R else how do you go stright on or is the device
going to go in ever decreasing circles ?
Just a small point.
Steve.......

1997\11\03@125755 by John Payson

picon face
> Since "forward" and "reverse" are mutually exclusive, you don't need
> four bits... If you use "0" for "reverse" and "1" for "forward", you
> can send the whole message in only TWO bits.
>
> Andy I think that maybe Stop maybe a good condition unless the object is to
> be in motion ad infinitum. This blows away the mutually exclusive theroy.

There are probably nine useful states (L and R may each by any of 3).  This
won't quite fit in 3 bits unless you forbid one or more states or state
transitions.

Alternatively, you might put in two forward speeds in which case both left
and right would have four states.

1997\11\03@134922 by Andrew Warren

face
flavicon
face
I wrote:

> Since "forward" and "reverse" are mutually exclusive, you don't need
> four bits... If you use "0" for "reverse" and "1" for "forward", you
> can send the whole message in only TWO bits.

and Steve Smith <.....PICLISTKILLspamspam.....MITVMA.MIT.EDU> replied:

> Andy I think that maybe Stop maybe a good condition unless the
> object is to be in motion ad infinitum. This blows away the mutually
> exclusive theroy.

then, John Payson <EraseMEsupercatspam_OUTspamTakeThisOuTMCS.NET> wrote:

> There are probably nine useful states (L and R may each by any of
> 3). This won't quite fit in 3 bits unless you forbid one or more
> states or state transitions.

   Steve:  I was imagining a system in which continuous reception of
   the signal was necessary in order for the thing to keep moving.
   To stop it, you'd simply stop sending the signal.

   John:  Since motion in an arc can be achieved (at low speeds,
   anyway) by a series of rotations and straight-line translations,
   you don't necessarily need to allow one motor to be stopped while
   the other turns.

   Nevertheless, you're both right... For the most flexibility and
   easiest implementation, four bits should be used.

   -Andy

=== Andrew Warren - fastfwdspamspam_OUTix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499

1997\11\03@145448 by Eric van Es

flavicon
face
Andrew Warren wrote:

>     Steve:  I was imagining a system in which continuous reception of
>     the signal was necessary in order for the thing to keep moving.
>     To stop it, you'd simply stop sending the signal.
>
>     John:  Since motion in an arc can be achieved (at low speeds,
>     anyway) by a series of rotations and straight-line translations,
>     you don't necessarily need to allow one motor to be stopped while
>     the other turns.
>
>     Nevertheless, you're both right... For the most flexibility and
>     easiest implementation, four bits should be used.
>
>     -Andy

Unless its a plane (or a canary.. :-) !

--
Eric van Es               | Cape Town, South Africa
@spam@vanesKILLspamspamilink.nis.za | http://www.nis.za/~vanes
LOOKING FOR TEMPORARY / HOLIDAY ACCOMODATION?
http://www.nis.za/~vanes/accom.htm

1997\11\05@073606 by paulb

flavicon
face
Andrew Warren wrote:

> Steve:  I was imagining a system in which continuous reception of
> the signal was necessary in order for the thing to keep moving.
> To stop it, you'd simply stop sending the signal.

 That's not too far out either.  I answered direct to Jose, but it
might JUST bear repeating, that for the remote control function, it
might be worth considering analogue systems that have been in the past,
or are presently used for ... remote control of vehicles/ models.

 As I see it, the "original" dual-channel analogue coding method was
called "simple-simul" and used a mechanical escapement to generate on-
off switching whose duty cycle coded one variable and repetition rate
coded the other, such as steering and speed.  You simply integrated the
output to determine the first variable, and used a "tachometer" circuit
(monostable triggered by the signal, then integrated) to determine the
other.

 This can be performed digitally quite easily; count up while the
carrier is on, count down while it is off, next time it goes on, the
cumulative result is your first parameter value, count the period from
one like transition to the next to derive the other parameter.

 This method can be made to contain redundancy quite easily, and fail-
safe (no carrier for too long; it stops) likewise.

 And the obvious alternative, a "digital" verson of which has been
mooted in this thread, is the pulse-width servo signalling as almost
universally used now for R/C models.

 Cheers,
       Paul B.

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