Help! Need to know how to do ManchesterEncoding/Decoding

Archiver

Hi,

I meant the shiftout instruction, sorry about that.
The serout can not be used for Manchester coding due to the serial
start/stop bits.

Debu did not specify the transmitter/receiver set he uses, but the available
RF
transmitter/receiver sets that accept/generate standard rs232 would already
implement some coding like manchester to get rid of any DC component and
to synchronize clocks. This is all transparent. The best way to go is to
focus
on datapackets and perhaps some error recovery methods, as suggested by
Tracy.
There is really no need to implement manchester coding for these RF sets.
However, if all you have is a very simple transmitter you must modulate
the datastream yourself. That is no easy task for a stamp!

Assuming you have an RF set that accepts rs232 consider the following
if you must apply manchester coding

'TRANSMITTER
charin var byte 'holds ASCII or binary character to send
wordout var word 'holds manchestercode for charin
bitcount var nib 'bitcounter

wordout=0
for bitcount=0 to 7
wordout=(wordout<<2)+charin.bit7+1 'add 1 or 2 after shifting
charin=charin<<1 'move next bit to bit7 position
next
serout pin,baud,[noparse][[/noparse]wordout.lowbyte,wordout.highbyte]

'RECEIVER
charout var byte 'holds ASCII or binary character to receive
chkout var byte 'holds the 'inverse' bits of charout
wordin var word 'holds received manchestercode for charout
bitcount var nib 'bitcounter

serin pin,baud,timeout,label,[noparse][[/noparse]wordin.low,wordin.high]
charout=0
chkout=0
for bitcount=0 to 7
charout=(charout<<1)+wordin.bit15 'bit15 is original bit of charin
chkout=(chkout<<1)+wordin.bit14 'bit14 is inverse of bit15
wordin=wordin<<2
next
if charout^chkout<>0 then errorlabel 'the xor result is 0 if ok
'process charout here

errorlabel:
'handle errors here

One special error is when the received wordin holds the highbyte of a sent
word
and the lowbyte of the next sent word. You could use a pause to synchronize
the
reception of words.

Good luck, peter

---

Oorspronkelijk bericht

---

Van: Tracy Allen [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=aYdqwVMEC5SXIGnEZLTxoo6ZZP8GGrdqKwYFjpPYo_4x75E5yIc_osf1SWpCbhF9KB3X-O7xg93LBmw0Pls]tracy@e...[/url
Verzonden: vrijdag 2 november 2001 21:24
Aan: basicstamps@yahoogroups.com
Onderwerp: RE: [noparse][[/noparse]basicstamps] Re: Help! Need to know how to do
ManchesterEncoding/Decoding

Hi,

Interesting links, Peter.

BTW the Stamp will choke on the instruction,

> serout pin,baud,[noparse][[/noparse]wordout\16]

serout does only bytes!

The "wordout\16" is okay for the shiftout command.

From what I understand of Manchester, it will be hard to implement on
the Stamp. The transmitting end needs to send an extended sychronous
bit stream, and the receiving end needs a phase lock loop to recover
the clock. The external chips Peter suggested would do that.

Debu, you might take a look at the documentation that comes with the
Parallax RF Digital tranceivers. They include some program examples
written by Jeff Martin that implement data packets and check sums.
The data packet and checksum scheme greatly improves the reliability
of the RF link. Maybe you can convince your instructor that
reliability is the goal of the assignment?! Even if you do implement
Manchester, you still might want to packetize your data.

It has never been clear to me if the RF Digital modules from Parallax
are strictly AM keyed, or if they implement a transparent Manchester
scheme. They do have a microprocessor on the RF transceiver board,
something the cheap RF modules do not have.

Simple AM keyed tranmitters are much more sensitive to noise when
they are OFF (not transmitting) than when they are ON
(transmitting). Therefore, a good transmission scheme will minimize
the off time. One reason Manchester encoding is good for RF is that
the transmitter is never off for more than two bit periods. When the
level at the input to the Manchester encoder is steady, either high
or low, the output of the Manchester is a steady stream of
on-off-on-off.

Jeff Martin had also written example programs for the
now-discontinued DVP modules, the aim of which was to implement a
transmission scheme on the BS2 that would hold the keyed AM
transmitter ON for most of the time, and minimize the off periods. I
don't see that document on line, but you might send an email to
Parallax to see if it might still be available.

-- best regards
Tracy Allen
electronically monitored ecosystems
http://www.emesystems.com
mailto:tracy@e...



>Hi,
>
>Take a look at the following link
>http://www.mycal.net/projects/digital/encode.html
>It provides program samples in C and a simple cheap circuit to filter out
>data at the receiver end.
>Also look at
>http://www.erg.abdn.ac.uk/users/gorry/course/phy-pages/man.html
>This shows the encoding: for a 0 send out 01 and for a 1 send out 10
>i.e add 1 or 2 after shifting the result 2 bits to the left
>You could encode in the following way:
>
>charin var byte 'holds ASCII or binary character to send
>wordout var word 'holds manchestercode for charin
>bit var nib 'bitcounter
>
>wordout=0
>for bit=0 to 7
> wordout=(wordout<<2)+charin.bit7+1 'add 1 or 2 after shifting
> charin=charin<<1 'move next bit to bit7 position
>next
>serout pin,baud,[noparse][[/noparse]wordout\16]
>
>hope this helps
>
>regards peter
>
>
>

---

Oorspronkelijk bericht

---

>Van: debu_sen_22@y... [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=dmGHKwWe-L4Ym1cGz3wJJOoSoaAqpHMwCcqByaCaQYlFQOsSfhQPHhXnDCd7hK2wRe3GFOyx8CYzmm1kqnwqVg]debu_sen_22@y...[/url
>Verzonden: donderdag 1 november 2001 19:08
>Aan: basicstamps@yahoogroups.com
>Onderwerp: [noparse][[/noparse]basicstamps] Re: Help! Need to know how to do Manchester
>Encoding/Decoding
>
>
>Yea, we can't use the chips because we would be over budget with our
>design project. We are trying to find a way to code it. Anyone have
>any other ideas?
>
>thanks
>
>Debu
>
>
>--- In basicstamps@y..., "peter verkaik" <peterverkaik@b...> wrote:
>> Hi,
>>
>> There are Manchester Encoding Decoding chips you can use.
>> Checkout:
> > http://www.intersil.com/data/FN/fn2/fn2959/FN2959.pdf
>> http://www.intersil.com/data/FN/fn2/fn2952/FN2952.pdf
>> You would place such a chip between stamp #1 and your transmitter
>and
>> between your receiver and stamp #2.
>> It should make the Manchester coding transparent to your program.
>However,
>> if the Manchester coding is part
>> of your assignment this would be cheating wouldn't it [noparse]:)[/noparse]
>>
>> regards peter
>>
>>
> >

---

Oorspronkelijk bericht

---

>> Van: debu_sen_22@y... [noparse][[/noparse]mailto:debu_sen_22@y...]
>> Verzonden: donderdag 1 november 2001 1:03
>> Aan: basicstamps@y...
>> Onderwerp: [noparse][[/noparse]basicstamps] Help! Need to know how to do Manchester
>> Encoding/Decoding
>>
>> Hi,
>>
>> I need some help with the Basic Stamp 2. I am building two vehicles
>> that will have the ability to transfer information to eachother as
>> they move around in areas. Our design project is using the Basic
>> Stamp 2 micro controller. My question is, i am required to do
> > Manchester Encoding/Decoding to send out and recieve the data via
>our
> > transceivers, and was wondering if anyone knows how to do this? If
> > so, please email me! As well, I was wondering if i can make a
> > circuit that can be connected to the serial out/in of the basic
>stamp
>> that will automatically convert it to manchester coding, instead of
>> having to code it for the micro controller?
>>
>> Thanks!
>>
>
> > Debu

To UNSUBSCRIBE, just send mail to:
basicstamps-unsubscribe@yahoogroups.com
from the same email address that you subscribed. Text in the Subject and
Body of the message will be ignored.


Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Archiver

Hi Peter, and Debu,


>Hi,
>
>I meant the shiftout instruction, sorry about that.
>The serout can not be used for Manchester coding due to the serial
>start/stop bits.

Not only that, shiftout needs its clock signal, which the Stamp
provides on a separate pin. Are you proposing that the clock signal
be sent through a separate radio link? On the receiving end it seems
to me the system would require an external chip to receive the data,
because the stamp shiftin command does not use an external clock.
The shiftin command operates in master, not slave mode.

Manchester coding scheme does not need a separate clock signal,
because its hardware recovers the clock from the transmitted data by
means of a phase lock loop. There has to be a preamble to the data,
a steady stream of on-off-on-off so that the loop can phase-lock to
the "0" state of the signal and can then detect the "1" of the start
bit. The Stamp can't do any of that without help from external
hardware.


>Debu did not specify the transmitter/receiver set he uses, but the available
>RF
>transmitter/receiver sets that accept/generate standard rs232 would already
>implement some coding like manchester to get rid of any DC component and
>to synchronize clocks. This is all transparent.

I think to get that, you have to spend more than $50 each for the
transmitter and receiver. Cheap modules that cost around $10 are
most certainly simple on-off keyed transmitters and straight-through
AM receivers.

>The best way to go is to
>focus
>on datapackets and perhaps some error recovery methods, as suggested by
>Tracy.
>There is really no need to implement manchester coding for these RF sets.
>However, if all you have is a very simple transmitter you must modulate
>the datastream yourself. That is no easy task for a stamp!
>
>Assuming you have an RF set that accepts rs232

The RF set accepts anything that turns the transmitter on and off, up
to a certain rate, that may max out at, say, 2400 baud.


>consider the following
>if you must apply manchester coding
>
>'TRANSMITTER
>charin var byte 'holds ASCII or binary character to send
>wordout var word 'holds manchestercode for charin
>bitcount var nib 'bitcounter
>
>wordout=0
>for bitcount=0 to 7
> wordout=(wordout<<2)+charin.bit7+1 'add 1 or 2 after shifting
> charin=charin<<1 'move next bit to bit7 position
>next
>serout pin,baud,[noparse][[/noparse]wordout.lowbyte,wordout.highbyte]
>
>'RECEIVER
>charout var byte 'holds ASCII or binary character to receive
>chkout var byte 'holds the 'inverse' bits of charout
>wordin var word 'holds received manchestercode for charout
>bitcount var nib 'bitcounter
>
>serin pin,baud,timeout,label,[noparse][[/noparse]wordin.low,wordin.high]
>charout=0
>chkout=0
>for bitcount=0 to 7
> charout=(charout<<1)+wordin.bit15 'bit15 is original
>bit of charin
> chkout=(chkout<<1)+wordin.bit14 'bit14 is inverse of bit15
> wordin=wordin<<2
>next
>if charout^chkout<>0 then errorlabel 'the xor result is 0 if ok
>'process charout here
>
>errorlabel:
>'handle errors here
>
>One special error is when the received wordin holds the highbyte of a sent
>word
>and the lowbyte of the next sent word. You could use a pause to synchronize
>the
>reception of words.
>

Nice program, Peter! I can't think of any way to eliminate the loop
structure to speed it up. Right, it is a tough one for the Stamp.
The issue of how to send and receive wordout and wordin remains,
given the need for a phase lock loop to recover the clock.

I think one could get pretty good results with asynchronous serout
and serin with this scheme though, kind of like you suggested in a
previous message. This would not be Manchester coding at the
physical layer, but it would address some of the issues of AM rf data
transmission. The main idea is to avoid long sequences of zeros in
the data stream. Set up the transmission and reception of the
Manchester encoded data as two serial bytes.

xmt:
'from Peter's code:
high 0 ' turn transmitter on
serout 0,$186,[noparse][[/noparse]wordout.byte0,wordout.byte1]
' transmitter is keyed off for start bit and zero bits only
' transmitter is otherwise on
low 0 ' turn transmitter off

rcv:
serin 0,baudmode,[noparse][[/noparse]wordin.byte0,wordin.byte1]
' to Peter's code
' the note about synchronization error still applies.

That addresses the issue that receivers are more sensitive to noise
in the off state than in the on state. The simple AM receivers do
not have any AGC circuitry, but if they did, that would kick in in
response to long sequences of 1s as well, and true Manchester would
certainly be called for. Simple receivers do not have AGC. They are
saturated by the rf signal, so that is why they are more sensitive to
noise when the transmitter is off. As the distance increases and the
signal to noise ratio degrades, the saturation in the on state is
also uncertain. The need for packetized data, CRCs etc becomes more
important. That is true whether or not Manchester encoding is
implemented.

Debu, do you think your instructor would let you get away with this
kind of "logic-layer" Manchester encoding for your assignment?

>
>
>Good luck, peter

--likewise,
Tracy Allen
electronically monitored ecosystems
mailto:tracy@e...
http://www.emesystems.com

Archiver

At 10:18 AM 11/3/01 -0800, Tracy Allen wrote:

>Manchester coding scheme does not need a separate clock signal,
>because its hardware recovers the clock from the transmitted data by
>means of a phase lock loop. There has to be a preamble to the data,
>a steady stream of on-off-on-off so that the loop can phase-lock to
>the "0" state of the signal and can then detect the "1" of the start
>bit. The Stamp can't do any of that without help from external
>hardware.

Sorry, but I have to disagree with a portion of the above.

Manchester encoding XORs the clock signal with the data signal. This
allows the clock to be recovered WITHOUT the benefit of a PLL. A simple
timer (software or hardware) and a latch to keep track of the previous bit
will do the trick. A slightly more complex version can allow the incoming
data polarity to be automatically detected so long as there is a break
period between packets.

As such, I'd guess that a stamp should be able to do low speed manchester
encoding and decoding. Since I don't write in PBASIC, I don't know this
for certain. But I have done it on a PIC.

Andrew Warren has written a nice description of how to decode a manchester
bit stream. You can look at his description at
http://pw2.netcom.com/~fastfwd/answers.html .

A brief description of manchester encoding:

Manchester encoding combines the clock and data of (typically) synchronous
data into one serial data stream. The combination is simply an X - NOR:
manchester data = NRZ data ^ (NRZ clock)' where NRZ data == Non-Return to
Zero data. A fancy way of saying there is no encoding i.e. a logic 1 is
+5 volts and a logic 0 is 0 volts. NRZ clock == A clock whose rising edge
occurs in the middle of each NRZ data bit

^ == exclusive or operator
( )' == The boolean complement operator

Here's an example comparing NRZ to Manchester: (view with mono-space font!)

-+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
NRZ | | | | | | | | | | | | | | | | |
clock +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--

+

---

+ +

---

+ +

---

+
NRZ | | | | | |
data -+ +

---

+ +

---

+ +---
1 0 1 0 0 1 1 1

Manchester +

---

+ +

---

+ +--+ +--+ +--+ +--+
Encoded | | | | | | | | | | | |
Data ----+ +

---

+ +--+ +

---

+ +--+ +--+ +--


Another way to think of Manchester encoding is split each bit into two
parts. A logic 1 is then transmitted as a 01 bit pair, a logic 0 is sent
as a 10 bit pair. The above diagram shows this clearly.


If you wish to "bit-bang" the serial data stream and decode the Manchester
data, typically, a bit-banging algorithm goes as follows.

1) Synchronize to the input data stream by hunting for an edge. For NRZ
data, you would hunt for the falling edge of the start bit. For
Manchester data, you will continuously have edges except during the
'break'
period.

2) Wait for one half bit time. Presumably, the data is "cleanest" in the
middle of a bit.

3) Wait for one whole bit time.

4) Sample the input data. Note that this sample will occur in the middle of
a bit.

5) Decode the data bit, i.e. convert from Manchester to NRZ.

6) go to step 3.

dwayne



Dwayne Reid <dwayner@p...>
Trinity Electronics Systems Ltd Edmonton, AB, CANADA
(780) 489-3199 voice (780) 487-6397 fax

Celebrating 17 years of Engineering Innovation (1984 - 2001)

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

Archiver

Hey,

I would like to thank you for the wonderful help i am getting. I
haven't had the time to look over the ideas that were given to me,
because at the moment I am studying for midterm exams (we all hate
this time of year). By the middle of this week, I am going to go
back to this project and work on it.

The reason why I said Manchester coding is because the person who we
bought our transceivers from (Abacom - www.abacom-tech.com AM-RTD-
315 is the part number) said that we will need to a) send a preamble
and b) somehow encode the data such as using Manchester coding. He
does sell a part that will do all of this for $30, however, we would
require 3 of them (= $90) and our budget for the project will not let
us purchase these parts (the University set a budget for the group),
PLUS, its good experience to somehow figure it out i guess.

One of my main problems I will have is that I am not really a strong
programmer. I really didn't know what manchester coding was until I
read up the 'basics' for it (ie, send a + to - for a 1 and - to + for
a 0).

Our project is basically two small cars that both will have the basic
stamp 2, and then we are going to have a base station which is a
computer. Each of these will have a transceiver, and we will be
prgramming the stamps in Pbasic (can u brogram them in any other
language?)... and, I sort of got to learn Pbasic. So much work, so
little time.. plus midterm exams.

I apologize for not giving exact information earlier... but, I hope
this clarifies some things.

But, thank you for all of your help. I will read it in more detail
during this week..!

Have a great weekend (what's left of it!)

Regards,

Debu

Archiver

Hi Dwayne,

Good point and a helpful explanation of how the coding works. The
link at http://pw2.netcom.com/~fastfwd/answers.html has a real nice
explanation too of Hamming codes in terms of natural language.

Thinking about it more, I think the phase lock loop would still have
a great advantage when when the channel is noisy. The whole
Manchester scheme depends on correct detection of the clock edges.
The PLL would reject pop noise and jitter and carry the decoding
system happily through short dropouts and bursts of noise.

Also, to get best results on a noisy channel, the determination of
"1" or "0" should not be made on the basis of one sample taken
halfway through the bit period. What if a "pop" happens right at
that instant? There should be majority logic based on several
samples during the bit period, or something like that. I'm just
talking bull--I'm sure the top-notch systems do something like that,
but maybe not the low-end wireless systems. Packetizing with CRCs
and error correction of some sort is the next layer up, and allows
recovery even if the channel is moderately noisy.

Thinking too about the conditions where Manchester coding would help.
I think it would have the most benefit where the receiver has AGC,
and not much benefit at all if the receiver does not have AGC.

(Automatic gain control for the newbies!. When the receiver does not
hear anything, it slowly and automatically turns up its gain until it
does hear something. And when what it hears is too loud, it slowly
and automatically turns down its gain until what it hears is not so
loud. The "attack" and the "decay" do not necessarily take place at
the same rate. If there is too much of a delay where the receiver
does not hear anything, it will dip down to the noise floor.)

In Manchester code the ON and OFF times are always very nearly equal,
within a factor of two, so it is possible to adjust the AGC very
accurately to receive the signal without dipping down to the noise
floor.

Some AM receivers, the cheapest ones, do not have any AGC. They are
simply an AM detector followed by a comparator, or they are
superregens. Superhet receivers usually do have AGC, but I don't see
in the Abacom <http://www.abacom-tech.com/> literature what the
parameters are or any control over them. The most expensive modules
(~100) include packetizing and encoding. The Micrel quickradio
chips <http://www.micrel.com/product-info/qwikradio.shtml> do have
AGC control.

Do you know of other reasons why Debu would need to use Manchester
coding? If they have the simple AM receiver, without AGC, then it
seems to me there is not much to be gained. I'm not sure about a
superregenerative detector. Regens have squelching that is kind of
like a detector and AGC all rolled into one.

-- regards,
Tracy Allen
electronically monitored ecosystems
mailto:tracy@e...
http://www.emesystems.com


>At 10:18 AM 11/3/01 -0800, Tracy Allen wrote:
>
> >Manchester coding scheme does not need a separate clock signal,
> >because its hardware recovers the clock from the transmitted data by
> >means of a phase lock loop. There has to be a preamble to the data,
> >a steady stream of on-off-on-off so that the loop can phase-lock to
> >the "0" state of the signal and can then detect the "1" of the start
> >bit. The Stamp can't do any of that without help from external
> >hardware.
>
>Sorry, but I have to disagree with a portion of the above.
>
>Manchester encoding XORs the clock signal with the data signal. This
>allows the clock to be recovered WITHOUT the benefit of a PLL. A simple
>timer (software or hardware) and a latch to keep track of the previous bit
>will do the trick. A slightly more complex version can allow the incoming
>data polarity to be automatically detected so long as there is a break
>period between packets.
>
>As such, I'd guess that a stamp should be able to do low speed manchester
>encoding and decoding. Since I don't write in PBASIC, I don't know this
>for certain. But I have done it on a PIC.
>
>Andrew Warren has written a nice description of how to decode a manchester
>bit stream. You can look at his description at
>http://pw2.netcom.com/~fastfwd/answers.html .
>
>A brief description of manchester encoding:
>
>Manchester encoding combines the clock and data of (typically) synchronous
>data into one serial data stream. The combination is simply an X - NOR:
>manchester data = NRZ data ^ (NRZ clock)' where NRZ data == Non-Return to
>Zero data. A fancy way of saying there is no encoding i.e. a logic 1 is
>+5 volts and a logic 0 is 0 volts. NRZ clock == A clock whose rising edge
>occurs in the middle of each NRZ data bit
>
> ^ == exclusive or operator
>( )' == The boolean complement operator
>
>Here's an example comparing NRZ to Manchester: (view with mono-space font!)
>
> -+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
>NRZ | | | | | | | | | | | | | | | | |
>clock +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--
>
> +

---

+ +

---

+ +

---

+
>NRZ | | | | | |
>data -+ +

---

+ +

---

+ +---
> 1 0 1 0 0 1 1 1
>
>Manchester +

---

+ +

---

+ +--+ +--+ +--+ +--+
>Encoded | | | | | | | | | | | |
>Data ----+ +

---

+ +--+ +

---

+ +--+ +--+ +--
>
>
>Another way to think of Manchester encoding is split each bit into two
>parts. A logic 1 is then transmitted as a 01 bit pair, a logic 0 is sent
>as a 10 bit pair. The above diagram shows this clearly.
>
>
>If you wish to "bit-bang" the serial data stream and decode the Manchester
>data, typically, a bit-banging algorithm goes as follows.
>
>1) Synchronize to the input data stream by hunting for an edge. For NRZ
> data, you would hunt for the falling edge of the start bit. For
> Manchester data, you will continuously have edges except during the
>'break'
> period.
>
>2) Wait for one half bit time. Presumably, the data is "cleanest" in the
> middle of a bit.
>
>3) Wait for one whole bit time.
>
>4) Sample the input data. Note that this sample will occur in the middle of
> a bit.
>
>5) Decode the data bit, i.e. convert from Manchester to NRZ.
>
>6) go to step 3.
>
>dwayne
>
>
>
>Dwayne Reid <dwayner@p...>
>Trinity Electronics Systems Ltd Edmonton, AB, CANADA
>(780) 489-3199 voice (780) 487-6397 fax
>
>Celebrating 17 years of Engineering Innovation (1984 - 2001)
>
>* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>Do NOT send unsolicited commercial email to this email address.
>This message neither grants consent to receive unsolicited
>commercial email nor is intended to solicit commercial email.
>
>
>To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
>from the same email address that you subscribed. Text in the
>Subject and Body of the message will be ignored.
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Archiver

>I am studying for midterm exams (we all hate
>this time of year).

Good luck!

>The reason why I said Manchester coding is because the person who we
>bought our transceivers from (Abacom - www.abacom-tech.com AM-RTD-
>315 is the part number) said that we will need to a) send a preamble
>and b) somehow encode the data such as using Manchester coding. He
>does sell a part that will do all of this for $30, however, we would
>require 3 of them (= $90) and our budget for the project will not let
>us purchase these parts (the University set a budget for the group),
>PLUS, its good experience to somehow figure it out i guess.
>
>One of my main problems I will have is that I am not really a strong
>programmer. I really didn't know what manchester coding was until I
>read up the 'basics' for it (ie, send a + to - for a 1 and - to + for
>a 0).
>
>Our project is basically two small cars that both will have the basic
>stamp 2, and then we are going to have a base station which is a
>computer. Each of these will have a transceiver, and we will be
>prgramming the stamps in Pbasic (can u brogram them in any other
>language?)... and, I sort of got to learn Pbasic. So much work, so
>little time.. plus midterm exams.
>
>I apologize for not giving exact information earlier... but, I hope
>this clarifies some things.

Okay, keep it simple at first and get it working at 10 meters range.
Something like,

serout 0,396,[noparse][[/noparse]$55,$55,commands,checksum]

The $55 "preamble" gets the receiver gain control "up to speed" (if
that applies to superregenerative receivers like your AM-RTD-315 -I'm
not sure.) and also gives the receiver some initial data to key in
on. The receiver can acknowledge the data or ask for a resend, based
on the checksum.

-- regards,
Tracy Allen
electronically monitored ecosystems
mailto:tracy@e...
http://www.emesystems.com



>But, thank you for all of your help. I will read it in more detail
>during this week..!
>
>Have a great weekend (what's left of it!)
>
>Regards,
>
>Debu

Archiver

At 01:55 PM 11/4/01 -0800, Tracy Allen wrote:

>Do you know of other reasons why Debu would need to use Manchester
>coding? If they have the simple AM receiver, without AGC, then it
>seems to me there is not much to be gained. I'm not sure about a
>superregenerative detector. Regens have squelching that is kind of
>like a detector and AGC all rolled into one.

I think you hit the nail right on its head when you mentioned nearly equal
1 and 0 bit time. My guess is that the data slicer on the receiver is AC
coupled. A massively unbalanced data stream (NRZ data) would probably
cause the data slicer to cease functioning after a couple of bytes. By the
same token, a data slicer training preamble before the actual data is
probably a good idea.

I also agree that a PLL on the recovered clock greatly improves noise
immunity. The point I wanted to make was that a Manchester encoded data
steam could in fact be decoded without one.

dwayne



Dwayne Reid <dwayner@p...>
Trinity Electronics Systems Ltd Edmonton, AB, CANADA
(780) 489-3199 voice (780) 487-6397 fax

Celebrating 17 years of Engineering Innovation (1984 - 2001)

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.